Complete status report is in : https://wiki.linaro.org/OfficeofCTO/WeeklyReport

Last meeting minutes: https://wiki.linaro.org/OfficeofCTO/2011-10-04

== Highlights == Please see the status report for more details.

* ARMHF: Benchmarking activity is going smoothly now. On the package porting side we have reached ~8200 packages done, still 90 to do. That's at 88-89%. You can follow the progress of this porting work - * http://buildd.debian-ports.org/status/architecture.php?a=armhf&suite=sid contains a high-level view of what packages are done and what is left to do * http://wiki.debian.org/ArmHardFloatTodo has a graph at the bottom of the page showing what is the percentage of the packages built for each architecture

* Boot Architecture: Regarding the scope of the work, the group created a list of the things to be worked on (both short term - focusing on ARM Server - and long term - strategic and design issues)

* Short term: resources are needed to cover this work - will be defined after discussing the prioritised list with the TSC * Support for Uboot * Kernel update process/method should be clarified * Making every uboot behave the same way * How does uboot decide what kernel to load - does not have to be uboot specific fix, could be a script for uboot * Single zImage able to boot on multiple SOCs * Support for grub on uboot. How will that help UEFI: distros would be able to have a bootloader under their control and can rely upon as expected also on x86. Could be done by adding support for syslinux configuration files, or porting port grub on uboot (as a uboot app called by EFI) * Port tianocore as a uboot app - how well does the driver model line up for that? The device model in uboot is pretty thin * Investigate GPT support for uboot - would it be troublesome with some SoCs (SoC specific code just to bootstrap stuff? You can have alongside the GPT a backwards compatibility boot table so you can have MBR and GPT happily coexisting) * Uboot should understand which is the active partition - or should have a mechanism to tell the user which is the active partition. E.g. in parted there is the bios-grub flag which indicates the boot partition. If we are booting off a block device the information of which is the boot partition comes from the disk.

* Long term: there is a keen vendors' interest in standards process - which the Linux community has not been extremely involved in the past. So the long-term target would be working with the standards - familiarise oneself with the existing standards (eg for x86 UEFI + ACPI v.4 - we should get familiar with those), and to provide feedback on those standards. One possible thread of work is to investigate DT support into the ACPI spec? What are the benefits of the DT, what are the merits of ACPI (this is already out there and we need to see how it fits in with Linux support on ARM). Ideally we should get towards a solution which bridges across the positive points between DT and ACPI.

Best regards,