Summary

  • Define a procedure for BSP investigations - what output is needed?
    • What lessons can we learn from previous investigations?
  • Define what BSP investigation work will be done over the coming cycle.

Design

Proposed work items as follows:

  • (linaro kernel) agree BSP review process based on UDS discussions
  • (linaro kernel) document the BSP review process on the wiki
  • (linaro kernel) define wiki location for collecting Linux BSP reviews
  • (linaro kernel) create a review report template for Linux BSP reviews on the wiki
  • (linaro kernel or foundations) define and agree U-Boot review process
  • (linaro kernel or foundations) document the U-Boot review process on the wiki
  • (linaro kernel or foundations) define wiki location for collecting U-Boot reviews
  • (linaro kernel or foundations) create a review report template for U-Boot reviews on the wiki
  • (linaro kernel) investigate and decide whether we should review Android BSPs
    • if yes, then the review process must be agreed and documented in a similar way to the process for standard Linux BSP reviews.
  • (linaro kernel) Create a common, public repository for BSP review tools
    • when reviewing, reviewers should attempt to automate the extraction of summary metrics etc., and contribute the resulting tools for use by all reviewers
    • the tools should be available to the SoC vendors so that they can reproduce what is reported in the review.
  • (linaro kernel) Freescale: conduct monthy reviews of i.MX Linux BSP starting with Freescale's imx_2.6.35_10.10.01 release branch.

  • (linaro kernel or foundations) Freescale: coordinate with vendor and review U-Boot at least once (suggest imx_v2009.08_10.10.01 release branch as initial review target)

  • (linaro kernel) ST-Ericsson: define schedule in coordination with vendor (suggestion: monthly) and target branch(es) for review
    • define work items for reviews when decided
  • (linaro karnel or foundations) ST-Ericsson: coordinate with vendor and review U-Boot at least once
  • (linaro kernel) TI: coordinate with vendor and conduct monthly reviews of omap3+4 Linux BSP tree on omapzoom.
    • review may be expanded to cover Android tree if the decision is made to review Android trees in general.
  • (linaro kernel or foundations) TI: coordinate with vendor and review U-Boot tree at least once
  • (linaro kernel or foundations) Samsung: coordinate with vendor and review U-Boot tree at least once
  • (dmart) Check whether a U-Boot review is required for ARM.

Proposed Linux BSP Review Process

  • For each BSP to review
    • Check you're reviewing the latest BSP
    • Run a tool to collect mechanical/technical information on the BSP
      • Check for suitable BSP review tools in a common review tool repository first (once it exists).
      • When creating new tools for conducting the review, these should be contributed to the common review tool repository before submitting the review report to the reviewee (SoC vendor).
    • Compare the contents of the BSP with the SoC features to make sure you're reviewing a full BSP
    • Check the BSP against a list of "features" or characteristics expected from new code (like DeviceTree compatibility, or relocation support etc.)

      • List of features to check for:
        • Ensure full NEON debug support (support all NEON/VFPv3 regs in ptrace() interface and coredumps)

        • Ensure kernel builds and works in Thumb-2 (CONFIG_THUMB2_KERNEL)

          • Dependent on hardware-n-kernel-standard-architecture blueprint
        • Ensure CONFIG_HIGHMEM works (trivial?)

    • Output a BSP review wiki page
      • Location and page template TBD

      • Start with a draft and then releasing a final version after review by a suitable linaro tech lead or kernel expert
      • Present reviews as a joint Linaro effort instead of a personal one
    • Propose changes to in-tree Documentation/ based on review output, as appropriate.

    • Feed back to linaro TSC based on review output, as appropriate.
      • e.g., to help define common recommendations made by linaro to SoC vendors

Implementation

Code Changes

Migration

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

hardware-n-bsp-investigations

Agenda

  • Define a procedure for BSP investigations - what output is needed?
    • What lessons can we learn from previous investigations?
  • Define what BSP investigation work will be done over the coming cycle.

Notes

2 BSP reviews so far:

  • freescale mx5/mx3 etc.
  • st-ericsson u8500

Goals of this effort are to:

  • help these BSPs go upstream; help SoC vendors to manage/reduce their delta
  • define future Linaro work -- BSPs are a glimpse into the future
  • provide tools and documentation to help vendors send BSP upstream

Important part of the BSP review is that it's public and gets distributed to the people working on the BSP

Having the BSP review public is mostly a lever to push companies to care about it

The ST-Ericsson review was good, and was perceived as harsh, but it was harsh enough to trigger reaction and a desire to fix it. However it didn't review the latest version of the code, and it didn't cover the full BSP and was missing things like media accelerator and graphics accelerator.

Review must include ALL kernel code as a strong requirement

Interested in GPL code for upstream purposes, and can normally only get that anyway.

Need to do it regularly, perhaps monthly and from multiple angles. Good to have reviewers to be experienced kernel people who can comment on style.

Output form for the ST-Ericsson BSP review was really good, and we can keep it as is. Ordering by subsystem is really what you want.

Would be nice to review the drivers/ subtree as well, and not mostly arch/arm/; this requires some specialists though.

Freescale review was different. How?

Does it make sense to review Android-flavored kernels? Need more of defined plan since Android patches are not more formatted.

Is the goal of the review to help Vendors make their BSPs more upstreamable?

We should translate some good review feedback into kernel Documentation/ files.

Do we need new tools to automate parts of the review like diff stats? Yes, can only do part of the job though Should report number of checkpatch errors/warnings etc. and automate this step checkpatch wrapper - http://people.redhat.com/mingo/tip.git/code-quality

How can Linaro help with the reviews going forward? Need a few review points within Linaro goals, checklist to assure frameworks and subsystems are existant. For instance, Linaro reviewers should check whether it's possible to implement device tree with the BSP by checking that the driver parameters are runtime determined rather than compile-time.

Extract some vendor specific approaches and make they more generic. Extract where it makes sense and where we can apply to other platforms.

Freescale review took place but not clear which portions were ready to up-stream and which portions need more work.

Suggestion one vendor review another vendor's BSP. Suggestion is Arnd does the reviews due to more community experience. However it's also smart to spread the work around to gain more experience in other areas.

Proposed BSP review process:

  • For each BSP to review
    • Check you're reviewing the latest BSP
    • Run a tool to collect mechanical/technical information on the BSP
    • Compare the contents of the BSP with the SoC features to make sure you're reviewing a full BSP
    • Check the BSP against a list of "features" or characteristics expected from new code (like DeviceTree compatibility, or relocation support etc.)

    • Output a BSP review wiki page
      • Start with a draft and then releasing a final version
      • Present review as a joint Linaro one instead of a personal one
    • Update kernel documentation
    • Try to summarize ideas of new Linaro developments that should be undertaken

Could work in pairs to do BSP reviews, and then exchange the BSP review draft with another pair of people for comments

Which BSPs are we going to review and should we review kernel along with uboot?

We should definitely review u-boot as well, perhaps with a lighter weight process

Action Items from BoF

  • Create a tool collecting statistics around BSP git trees, running checkpatch, diffstat etc.
  • Document the BSP review process
  • Do some BSP reviews for:
    • Freescale: i.mx BSP releases monthly; we should try to review each of them
    • ST-Ericsson: no official BSP release, could push for a code drop every month and review that
      • Currently two trees, but will be one generic base tree in the future and it should be the one we review
    • ARM: upstreaming patches continuously, not necessary for Linaro, already a lot of coverage
      • ACTION Dave to check with Peter Pearse whether there's interest in an ARM u-boot review
    • TI: 2 BSPs internally, one Android and non-Android, for OMAP3 and OMAP4, on omapzoom; monthly release; at most one kernel version behind.
    • Samsung: 1 BSP, mainstream now. Review process is work directly with mainline - probably no review needed? u-boot would need a review though


CategorySpec

WorkingGroups/KernelArchived/Specs/BSPInvestigations (last modified 2013-01-14 19:40:41)