Pack firmware into an image and do update in factory install process.

Pack firmware into an image and do update in factory install process.

Since different platforms have different instructions to update their firmware. In order not to depend on the install shim, we pack all firmware update files into a single file, i.e. an executable shell script with embedded files.

This CL is now broken into 5 CLs in different git repositories:
http://codereview.chromium.org/2792013
http://codereview.chromium.org/2767011
http://codereview.chromium.org/2795004
http://codereview.chromium.org/2794006
http://codereview.chromium.org/2715012

[Nick Sanders, 2010-05-28 22:01:48]

http://codereview.chromium.org/2366001/diff/1/3
File src/platform/factory_installer/factory_install.sh (right):

http://codereview.chromium.org/2366001/diff/1/3#newcode45
src/platform/factory_installer/factory_install.sh:45: for i in EFI OEM STATE
RELEASE FACTORY FIRMWARE; do
Will it fail if there's no firmware update available?

http://codereview.chromium.org/2366001/diff/1/6
File src/platform/memento_softwareupdate/memento_updater.sh (right):

http://codereview.chromium.org/2366001/diff/1/6#newcode323
src/platform/memento_softwareupdate/memento_updater.sh:323: if [
"${FLAGS_force_track}" = "firmware-channel" ]; then
Naming is a bit odd here..

[adlr, 2010-06-01 22:11:18]

http://codereview.chromium.org/2366001/diff/1/4
File src/platform/firmware/x86-generic/install_firmware.sh (right):

http://codereview.chromium.org/2366001/diff/1/4#newcode1
src/platform/firmware/x86-generic/install_firmware.sh:1: #!/bin/bash
our final image won't have bash, so please switch this to just /bin/sh

http://codereview.chromium.org/2366001/diff/1/5
File src/platform/firmware/x86-generic/pack_firmware.sh (right):

http://codereview.chromium.org/2366001/diff/1/5#newcode1
src/platform/firmware/x86-generic/pack_firmware.sh:1: #!/bin/bash
if this should run on the image, switch to /bin/sh

[Tom Wai-Hong Tam, 2010-06-02 12:13:15]

Tested and worked in factory install shim.

http://codereview.chromium.org/2366001/diff/1/3
File src/platform/factory_installer/factory_install.sh (right):

http://codereview.chromium.org/2366001/diff/1/3#newcode45
src/platform/factory_installer/factory_install.sh:45: for i in EFI OEM STATE
RELEASE FACTORY FIRMWARE; do
Fixed it. Firmware update is optional. If it finds no firmware image in
devserver, still continues.

http://codereview.chromium.org/2366001/diff/1/4
File src/platform/firmware/x86-generic/install_firmware.sh (right):

http://codereview.chromium.org/2366001/diff/1/4#newcode1
src/platform/firmware/x86-generic/install_firmware.sh:1: #!/bin/bash
Done.

http://codereview.chromium.org/2366001/diff/1/5
File src/platform/firmware/x86-generic/pack_firmware.sh (right):

http://codereview.chromium.org/2366001/diff/1/5#newcode1
src/platform/firmware/x86-generic/pack_firmware.sh:1: #!/bin/bash
It runs inside chroot. So it's OK.

http://codereview.chromium.org/2366001/diff/1/6
File src/platform/memento_softwareupdate/memento_updater.sh (right):

http://codereview.chromium.org/2366001/diff/1/6#newcode323
src/platform/memento_softwareupdate/memento_updater.sh:323: if [
"${FLAGS_force_track}" = "firmware-channel" ]; then
We use *-channel to communicate with devserver. Do you have a better name for
this channel?

[adlr, 2010-06-02 16:53:14]

LGTM if nsanders is happy

[Nick Sanders, 2010-06-02 19:36:32]

lgtm w/ those changes..

http://codereview.chromium.org/2366001/diff/16001/17002
File src/platform/factory_installer/factory_install.sh (right):

http://codereview.chromium.org/2366001/diff/16001/17002#newcode68
src/platform/factory_installer/factory_install.sh:68: if [ "$RESULT" !=
"UPDATED" ]; then
can you add allowing non-updated firmware here? Might be cleaner to disregard
the no-update results, than always return "updated" whether or not any update
occurred..

http://codereview.chromium.org/2366001/diff/16001/17005
File src/platform/memento_softwareupdate/memento_updater.sh (right):

http://codereview.chromium.org/2366001/diff/16001/17005#newcode328
src/platform/memento_softwareupdate/memento_updater.sh:328: log execute
firmware-install script
Can you set another var here named "install file" or something from
FLAGS_dst_partition" so it's clearer that this isn't a partition?

[Tom Wai-Hong Tam, 2010-06-03 08:36:22]

http://codereview.chromium.org/2366001/diff/16001/17002
File src/platform/factory_installer/factory_install.sh (right):

http://codereview.chromium.org/2366001/diff/16001/17002#newcode68
src/platform/factory_installer/factory_install.sh:68: if [ "$RESULT" !=
"UPDATED" ]; then
On 2010/06/02 19:36:32, Nick Sanders wrote:
> can you add allowing non-updated firmware here? Might be cleaner to disregard
> the no-update results, than always return "updated" whether or not any update
> occurred.. 

Done.

http://codereview.chromium.org/2366001/diff/16001/17005
File src/platform/memento_softwareupdate/memento_updater.sh (right):

http://codereview.chromium.org/2366001/diff/16001/17005#newcode328
src/platform/memento_softwareupdate/memento_updater.sh:328: log execute
firmware-install script
On 2010/06/02 19:36:32, Nick Sanders wrote:
> Can you set another var here named "install file" or something from
> FLAGS_dst_partition" so it's clearer that this isn't a partition?
> 

Done.

[Nick Sanders, 2010-06-03 21:27:24]

lgtm

[Tom Wai-Hong Tam, 2010-06-07 09:49:35]

Due to the reorganization of git repo that each subdirectory under platform has
its own git, this CL is divided into several CLs that belong to other gits:
  http://codereview.chromium.org/2690004 ;
  http://codereview.chromium.org/2640006 ;
  http://codereview.chromium.org/2694005 ;
  and the one under platform/firmware is waiting for the creation of the
firmware git.

I didn't change anything additional.

[anush, 2010-06-07 15:08:05]

Does it make sense to consider putting the code in platform/firmware
as a tarball ebuild (cros-binary.eclass) without creating a repo for
it?  i.e we create a tarball of the binary bits that is available on
our mirror and we have an ebuild that pulls it down and installs it.

We also seem to be recreating the board hierarchy again under
platform/firmware.

Thanks
Anush

On Mon, Jun 7, 2010 at 2:49 AM,  <waihong@chromium.org> wrote:
> Due to the reorganization of git repo that each subdirectory under platform
> has
> its own git, this CL is divided into several CLs that belong to other gits:
>  http://codereview.chromium.org/2690004 ;
>  http://codereview.chromium.org/2640006 ;
>  http://codereview.chromium.org/2694005 ;
>  and the one under platform/firmware is waiting for the creation of the
> firmware git.
>
> I didn't change anything additional.
>
> http://codereview.chromium.org/2366001/show
>

[Tom Wai-Hong Tam, 2010-06-08 02:06:17]

I am not familiar with ebuild and may misunderstand. Please correct if I am
wrong.

platform/firmware contains not only the firmware binary, but also the
instructions how to flash the firmware to eeprom, like writing some register
before flashing, flashing a pre-definited region, enabling write protection,
etc.

Those things in platform/firmware are then packed by a script
(script/make_factory_package.sh) into an image and hosted on dev server.
During factory install, it is downloaded and installed to the firmware. It
is not directly emerged into the ChromeOS image. My understanding is it is
not the case like cros-binary.

Tom

On Mon, Jun 7, 2010 at 10:59 PM, Anush Elangovan <anush@chromium.org> wrote:

> Does it make sense to consider putting the code in platform/firmware
> as a tarball ebuild (cros-binary.eclass) without creating a repo for
> it?  i.e we create a tarball of the binary bits that is available on
> our mirror and we have an ebuild that pulls it down and installs it.
>
> We also seem to be recreating the board hierarchy again under
> platform/firmware.
>
> Thanks
> Anush
>
> On Mon, Jun 7, 2010 at 2:49 AM,  <waihong@chromium.org> wrote:
> > Due to the reorganization of git repo that each subdirectory under
> platform
> > has
> > its own git, this CL is divided into several CLs that belong to other
> gits:
> >  http://codereview.chromium.org/2690004 ;
> >  http://codereview.chromium.org/2640006 ;
> >  http://codereview.chromium.org/2694005 ;
> >  and the one under platform/firmware is waiting for the creation of the
> > firmware git.
> >
> > I didn't change anything additional.
> >
> > http://codereview.chromium.org/2366001/show
> >
>

[anush, 2010-06-09 05:55:27]

Tom,
  I think then we should just write an ebuild that installs the
package like a "regular" package and the files could be put in
/usr/share/cros_firmware or similar.  You also want to keep the
factory shell scripts in the /usr/bin/cros_factory_*.
The idea is you version these tools with ebuilds.

Thanks
Anush

On Mon, Jun 7, 2010 at 7:05 PM, Tom Wai-Hong Tam (談偉航)
<waihong@chromium.org> wrote:
> I am not familiar with ebuild and may misunderstand. Please correct if I am
> wrong.
> platform/firmware contains not only the firmware binary, but also the
> instructions how to flash the firmware to eeprom, like writing some register
> before flashing, flashing a pre-definited region, enabling write protection,
> etc.
> Those things in platform/firmware are then packed by a script
> (script/make_factory_package.sh) into an image and hosted on dev server.
> During factory install, it is downloaded and installed to the firmware. It
> is not directly emerged into the ChromeOS image. My understanding is it is
> not the case like cros-binary.
> Tom
> On Mon, Jun 7, 2010 at 10:59 PM, Anush Elangovan <anush@chromium.org> wrote:
>>
>> Does it make sense to consider putting the code in platform/firmware
>> as a tarball ebuild (cros-binary.eclass) without creating a repo for
>> it?  i.e we create a tarball of the binary bits that is available on
>> our mirror and we have an ebuild that pulls it down and installs it.
>>
>> We also seem to be recreating the board hierarchy again under
>> platform/firmware.
>>
>> Thanks
>> Anush
>>
>> On Mon, Jun 7, 2010 at 2:49 AM,  <waihong@chromium.org> wrote:
>> > Due to the reorganization of git repo that each subdirectory under
>> > platform
>> > has
>> > its own git, this CL is divided into several CLs that belong to other
>> > gits:
>> >  http://codereview.chromium.org/2690004 ;
>> >  http://codereview.chromium.org/2640006 ;
>> >  http://codereview.chromium.org/2694005 ;
>> >  and the one under platform/firmware is waiting for the creation of the
>> > firmware git.
>> >
>> > I didn't change anything additional.
>> >
>> > http://codereview.chromium.org/2366001/show
>> >
>
>

[Tom Wai-Hong Tam, 2010-06-09 07:37:56]

We can do that, writing an ebuild that installs those things to the *factory
install shim*, a SD card image. For more about the factory install and test
flow, see
https://docs1.google.com/a/google.com/document/edit?id=1-QPLfDz2xeTLal1Zj0j7c...
.

But the problem is if we do some modifications on firmware later, we need to
rebuild the factory install shim again. The functionality of the shim is
simple, only for boot-up, connecting to sever and installing images (factory
images, release images, and firmware images). We want to keep the shim not
update frequently. So we move the all firmware related things (scripts and
firmware images) in server side. The shim downloads them and execute the
script. And we use some scripts to pack them into a single file instead of
emerge.

Tom

On Wed, Jun 9, 2010 at 1:55 PM, Anush Elangovan <anush@chromium.org> wrote:

> Tom,
>  I think then we should just write an ebuild that installs the
> package like a "regular" package and the files could be put in
> /usr/share/cros_firmware or similar.  You also want to keep the
> factory shell scripts in the /usr/bin/cros_factory_*.
> The idea is you version these tools with ebuilds.
>
> Thanks
> Anush
>
> On Mon, Jun 7, 2010 at 7:05 PM, Tom Wai-Hong Tam (談偉航)
> <waihong@chromium.org> wrote:
> > I am not familiar with ebuild and may misunderstand. Please correct if I
> am
> > wrong.
> > platform/firmware contains not only the firmware binary, but also the
> > instructions how to flash the firmware to eeprom, like writing some
> register
> > before flashing, flashing a pre-definited region, enabling write
> protection,
> > etc.
> > Those things in platform/firmware are then packed by a script
> > (script/make_factory_package.sh) into an image and hosted on dev server.
> > During factory install, it is downloaded and installed to the firmware.
> It
> > is not directly emerged into the ChromeOS image. My understanding is it
> is
> > not the case like cros-binary.
> > Tom
> > On Mon, Jun 7, 2010 at 10:59 PM, Anush Elangovan <anush@chromium.org>
> wrote:
> >>
> >> Does it make sense to consider putting the code in platform/firmware
> >> as a tarball ebuild (cros-binary.eclass) without creating a repo for
> >> it?  i.e we create a tarball of the binary bits that is available on
> >> our mirror and we have an ebuild that pulls it down and installs it.
> >>
> >> We also seem to be recreating the board hierarchy again under
> >> platform/firmware.
> >>
> >> Thanks
> >> Anush
> >>
> >> On Mon, Jun 7, 2010 at 2:49 AM,  <waihong@chromium.org> wrote:
> >> > Due to the reorganization of git repo that each subdirectory under
> >> > platform
> >> > has
> >> > its own git, this CL is divided into several CLs that belong to other
> >> > gits:
> >> >  http://codereview.chromium.org/2690004 ;
> >> >  http://codereview.chromium.org/2640006 ;
> >> >  http://codereview.chromium.org/2694005 ;
> >> >  and the one under platform/firmware is waiting for the creation of
> the
> >> > firmware git.
> >> >
> >> > I didn't change anything additional.
> >> >
> >> > http://codereview.chromium.org/2366001/show
> >> >
> >
> >
>

[Tom Wai-Hong Tam, 2010-06-11 07:40:46]

This CL is now broken into 5 CLs in different git repositories:
http://codereview.chromium.org/2792013
http://codereview.chromium.org/2767011
http://codereview.chromium.org/2795004
http://codereview.chromium.org/2794006
http://codereview.chromium.org/2715012