Uncategorized

Linaro Binary Toolchain Release GCC 6.3-2017.02

Linaro does regular drops of core tools, and these days they’re using GCC v6.x, and GCC has a few new language features and target architecture features recently. Excerpting the Linaro announcement:

The Linaro GCC 6.3-2017.02 Release is now available. […]  The Linaro binary toolchain is a collection of x86-hosted GNU cross-toolchains targeting a variety of ARM architecture targets. Linaro TCWG provides these toolchains as a service to our members. Due to hardware availability, system-image availability, validation complexity, and user-base size, not all host and target toolchain combinations can be validated by Linaro with the same rigor. The most rigorously validated targets are little-endian and hardfloat implementations of the 32-bit ARMv7 (arm), 32-bit ARMv8 (armv8), and 64-bit ARMv8 (aarch64) architectures.  Linaro recommends those targets to our members. […] The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc’s memcpy API. Linaro recommends using the 64-bit x86_64 host toolchains as the 32-bit i686 host toolchains and the 32-bit mingw host toolchains will only be provided as long as there is sufficient member interest to justify their continued availability. […] The GCC 6 Release series has significant changes from the GCC 5 release series.  For an explanation of the changes please see the following website[1]. For help in porting to GCC 6 please see the following explanation[2]. […]

[1] https://gcc.gnu.org/gcc-6/changes.html
[2] https://gcc.gnu.org/gcc-6/porting_to.html
https://gcc.gnu.org/onlinedocs/

http://releases.linaro.org/components/toolchain/gcc-linaro/6.3-2017.02/
http://releases.linaro.org/components/toolchain/binaries/6.3-2017.02/
http://snapshots.linaro.org/components/toolchain/binaries/

See the full announcement for more details:
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Standard
Uncategorized

Olimex releases TERES I, open source hardware ARM laptop

We are proud to announce that our TERES I laptop is complete. We have assembled units and now working on the software. The building instructions are uploaded here and you can see that it’s pretty easy to build one yourself. This weekend in Bruxell at FOSDEM we will have table in Hall AW where every one could touch and play with the very first built laptops. All spare parts are uploaded at the web. Hardware CAD files and Linux build scripts are on GitHub. TERES I is completely designed with KiCAD FOSS so everyone can download and learn, study, edit, modify. Hardwarewise everything is OK and works, the software need some care to be completed, power supply management, Linux distribution, and few more details need attention, but we hope everything to be complete till Friday!

TERES I was the first king of the Odrysian state of Thrace where Plovdiv is also located.

One of the files on github mentions:

In progress
To Do
[…]
* Clean binary blobs if possible
[…]

https://www.olimex.com/Products/DIY%20Laptop/KITS/
https://github.com/OLIMEX/DIY-LAPTOP
https://olimex.wordpress.com/2017/02/01/teres-i-do-it-yourself-open-source-hardware-and-software-hackers-friendly-laptop-is-complete/

Standard
Uncategorized

OpenSynergy hypervisor for ARM Cortex-R52

Quoting the press release:

Automotive safety hypervisor announced for ARM Cortex-R52
OpenSynergy paves way for next-generation autonomous devices with virtualization for ARM’s most advanced real-time processor

Berlin, Germany and Cambridge, UK, January 18, 2017. OpenSynergy is developing the industry’s first software hypervisor for the ARM® Cortex®-R52 processor, ARM’s most advanced real-time safety processor. The hypervisor turns any chip based on the Cortex-R52 into several virtual machines capable of simultaneously executing separate software tasks. To address increasing software complexity in devices such as autonomous vehicles and industrial control systems, this approach allows for the isolation of safety-critical functions from those that require less stringent control. In addition, it enables the consolidation of applications onto fewer electronic control units (ECUs) to both manage complexity and reduce cost. “Mass-market autonomous vehicles will be engineered with greatly enhanced ECU compute capabilities and the ability to safely manage far more complex software stacks,” said Richard York, vice president of embedded marketing, ARM. “The Cortex-R52 was purpose-built for this task, with hypervisor-enabled software separation protecting critical safety features while ensuring fast task execution. This will enable highly performant vehicles that can be fully trusted to take over from the driver.” “The ARM Cortex-R52 processor will bring virtualization technology to a much wider set of devices in the automotive market,” said Stefaan Sonck Thiebaut, CEO, OpenSynergy. “In doing so, we look forward to enabling the next generation of vehicle architecture.” The Cortex-R52 introduces hardware support for virtualization to the Cortex-R family of processors while maintaining all the functionality required for hard real-time systems. The ability to maintain deterministic execution within a hypervisor provides an ideal solution to the challenge of concurrent real-time systems in a wide array of robotic applications. OpenSynergy’s software architecture targets microcontrollers such as domain controllers. The hypervisor technology enables several real-time operating systems and AUTOSAR systems at different ASIL levels to run in parallel on the Cortex-R52.

Full PR:

https://www.arm.com/about/newsroom/automotive-safety-hypervisor-announced-for-arm-cortex-r52.php

http://www.opensynergy.com/fileadmin/user_upload/Presse/Pressemitteilungen/ARM_Cortex-R52_hypervisor_EN.pdf

Standard
Uncategorized

Leif on QEMU and USB host device pass-through

Leif has a new blog post on using UEFI with USB pass-through.

[…]”One thing that is unsurprising, but very cool and useful, is that this works well cross-architecture. So you can test that your drivers are truly portable by building (and testing) them for AARCH64, EBC and X64 without having to move around between physical machines.

http://blog.eciton.net/uefi/qemu-usb-passthrough.html

Checkout his previous blog post, on UEFI driver development, as well as older posts on Linaro/ARM/UEFI history.

 

Standard
Uncategorized

Writing secure C code for ARM

https://www.community.arm.com/iot/embedded/b/blog/posts/a-few-intricacies-of-writing-armv8-m-secure-code

https://www.community.arm.com/processors/b/blog/posts/useful-tips-for-developing-secure-software-on-armv8-m

https://www.community.arm.com/processors/b/documents/posts/whitepaper—armv8-m-architecture-technical-overview

https://developer.arm.com/products/architecture/m-profile/docs/100720/latest/secure-software-guidelines

https://developer.arm.com/docs/100739_0100/latest/the-arm-c-language-extensions-acle-for-armv8m

Standard
Uncategorized

new AArch64 vm-spec validation tools

Riku Voipio of Linaro has announced the release of some new tools that validate the VM to the Linux cross-distro list.

Some time ago we drafted a specification[1] for AArch64 virtual machines. Now we are launching verification tools that let everyone verify that the whole stack (host hypervisor, guest firmware and guest OS image) implements the spec 2[]. For some extra background see the blog post on vmspec [3]. From the cross-distro point of view, we are interested in finding out if
– QEMU shipped is new enough (2.6+)
– a compatible EFI for arm64 guests is available
– a vmspec compatible cloud guest image is available

If the image comes with cloud-init, vmspec-boot can be used directly to verify compliance. Without cloud-init, one can run vmspec-verify inside the guest to verify manually. The tools are still under development, for example the ACPI test returns a failure even if the guest would support ACPI if forced. Feedback and patches are always welcome. The README.md lists a handful of guest images that have been used in testing. I’d be most happy to add more links to the list!

[1] http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v2.0.pdf
[2] https://github.com/linaro/vmspec-tools
[3] http://www.linaro.org/blog/core-dump/ensuring-bootable-arm-vm-images/
Full message:
https://lists.linaro.org/mailman/listinfo/cross-distro

Standard