Firmware release procedures: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
mNo edit summary |
||
Line 49: | Line 49: | ||
cd quanta-ec |
cd quanta-ec |
||
cp /latestec . |
cp /latestec . |
||
git add latestec # this line only needs to be run the first time |
git add latestec # this line only needs to be run the first time through |
||
git commit -a # this will prompt for a commit message, which should be the changelog |
git commit -a # this will prompt for a commit message, which should be the changelog |
||
git push --all |
git push --all |
Revision as of 21:26, 13 October 2006
Release procedure
Here is a draft of a BIOS release procedure.
Stage one: EC:
- Quanta stores current EC build in a laptop.org GIT tree
- along with EC changelog and file hashes
- see notes below
- Quanta and OLPC test this version of EC
- Quanta tags for release
- Quanta sends mail to OLPC announcing the release, along with hashes from their build system
- OLPC acknowledges receipt
Stage two: Buildrom:
- Pull EC release from GIT, check hashes
- Update buildrom changelog and tag for release
- Update SPI flash version string in buildrom binary
- Create buildrom SRPM
- Build two flavors of binary RPM for the two RAM variants
- check with Ray -- do we need separate EC code for A-test and B-test?
Stage three: Testing:
- announce build to BIOS team and Ray, release candidate testing begins
- wmb to test on a 256M board
- install the binary RPMs on Tinderbox machines
- >12 hours of burn-in warm reboot testing on Tinderbox
- cold boot tests
- we need a cold boot solution; X10 doesn't seem to like the power at OLPC
- After automated tests, send "Who has tested?" mail asking for problem reports
- Release after twelve hours if no problem reports
Stage four: Release:
- Release builds kept in a separate directory
- Update the version number in LB from release candidate to final
- Could we do this without rebuilding and changing the hashes?
- Announce new build and hashes to devel-boards@ (requires moderation).
Using GIT for EC code
Using a revision-control system allows us to keep a copy of old EC releases, the changes between releases, and to know which EC binary was part of which release. There is already a GIT server running on laptop.org; the appropriate person at Quanta would need to install GIT and SSH, both of which work under Cygwin, and would need to send us their SSH public key.
A draft set of instructions would be:
git clone git+ssh://user@dev.laptop.org/git/projects/quanta-ec cd quanta-ec cp /latestec . git add latestec # this line only needs to be run the first time through git commit -a # this will prompt for a commit message, which should be the changelog git push --all
There is a GIT tutorial here, and our own instructions here.