Ticket #11146 (closed task: fixed)

Opened 3 years ago

Last modified 3 years ago

XO-1.75 automatic firmware update triggered by installed operating system build

Reported by: greenfeld Owned by: cjb
Priority: normal Milestone: 1.75-software
Component: distro Version: Development build as of this date
Keywords: Cc: pbrobinson
Action Needed: no action Verified: no
Deployments affected: Blocked By: #11071
Blocking: #11185

Description

Right now XO-1.75's do not automatically update their firmware when a new OS image is installed.

When appropriate, we should start adding the bootfw package (currently at q4b07?) for XO-1.75 to the 1.75 image build.

Change History

Changed 3 years ago by pbrobinson

I think it would be easier if we create a single srpm package with 3 noarch packages containing the bootfw for the 3 devices. Any thoughts either way?

Changed 3 years ago by Quozl

  • next_action changed from diagnose to design
  • type changed from defect to task
  • version changed from 1.75-B1 to Development build as of this date
  • summary changed from Add bootfw package to 1.75 build to XO-1.75 automatic firmware update triggered by installed operating system build

@greenfeld, you propose solving this by adding package.

The automatic update is normally (XO-1, XO-1.5) handled by the installed operating system build using the /bootpart/olpc.fth file, which is currently (XO-1.75 os36) provided by olpc-os-builder, but would normally (XO-1, XO-1.5) be provided by bootfw package.

Now that kernels provide /proc/device-tree, the XO-1.75 specific olpc.fth can be reduced significantly. But I'm not sure that is a good idea.

olpc.fth is maintained by the packagers of bootfw*.rpm, which are Richard Smith, Paul Fox, Mitch Bradley, and I, depending on who turns the crank. It's not under version control. I think it shouldn't be part of OpenFirmware or the bootfw*.rpm, but that's the way it is at the moment. I'd like to see that change.

@pbrobinson, unless there's a particularly good reason for changing how the packages are built, I prefer to leave them as they are. I've already changed XO-1.75's bootfw build to noarch, and both q4b06 and q4b07 are noarch. XO-1 and XO-1.5 packages are still i386, but a future release may change them to noarch #11055.

I see no reason why we need to provide .srpm, given that the current .srpm is binary and not source, and a different version of the source is used for the three laptop models. We don't release upstream and then carve three firmware blobs from it. Each is released in turn.

Changed distro component owner to pbrobinson.

Related tickets #11061 (firmware update security)

Changed 3 years ago by Quozl

os40 contains bootfw package, and /boot/bootfw.zip but olpc.fth is still in need of adjustment.

Changed 3 years ago by pbrobinson

  • next_action changed from design to test in build

bootfw-q4b08 is in build OS41

Changed 3 years ago by Quozl

  • next_action changed from test in build to design

No, olpc.fth is overwritten by olpc-os-builder, so olpc.fth is still in need of adjustment, and as a result automatic firmware update does not occur.

Changed 3 years ago by Quozl

  • blocking 11185 added

(In #11185) I've grabbed an SD card, then

mkfs -t ext4 /dev/mmcblk1p1
mkfs -t ext4 /dev/mmcblk1p2

It easily reproduces.

This is caused by not using the correct olpc.fth ... which would normally pass a different root option to the kernel. Workaround is to edit the /bootpart/olpc.fth file, changing mmcblk0 to mmcblk1. This can be done using emacs in OpenFirmware:

ok emacs int:\boot\olpc.fth

This will be solved when #11146 is also solved.

Not specific to hardware version, is specific to software builds.

Changed 3 years ago by Quozl

  • blockedby 11071 added

Changed 3 years ago by Quozl

  • blockedby 11071 removed

(In #11071) Related #11061 #11146.

Changed 3 years ago by Quozl

  • blockedby 11071 added

Changed 3 years ago by Quozl

  • next_action changed from design to no action

Works on os4, correctly reflashes to Q4B09.

Changed 3 years ago by Quozl

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.