Re: Migrating XO-1.75 to device tree - upgrade considerations
Thanks everyone for the discussion. I know this issue is not the #1 priority right now so I've summarised it in a wiki page: http://wiki.laptop.org/go/Device_tree_upgrade_considerations (edits welcome) We can revisit the topic at a point in the near future. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Wed, Aug 22, 2012 at 06:00:21PM -0500, Jerry Vonau wrote: > Yes it did at one point, way back when sparse support was first > added to the .zd files in order to gain the speed advantage offered > the required firmware must be installed first. That's not how I remember it. Sparse support worked but generated a minor warning. You wanted the firmware upgrade to avoid the warning. You might instead have suppressed the warning. http://wiki.laptop.org/go/User:Quozl/fs-update-skip-unused-blocks#Existing_Builds > After an OS upgrade we can't expect a teacher to boot each XO with > an AC adapter plugged-in when there maybe only one adaptor available > for the class or no AC at all because of the use of alternate > charging methods. I wonder how this is handled in other deployments > that are using solar-panels or hand cranks because there is no AC > available. We have chosen to have the firmware installed from a USB > drive as we can disable the AC check, and use the charge level of > the battery to ensure there is enough power present to ensure > success with the updating processes with our olpc.fth script. We know the battery state of charge may be unreliable under certain conditions, and that's one reason why we also require external power, as well as a minimum voltage and charge state. I'm glad you've taken on that risk, but not all deployments have such a high level of technical support and literacy. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On 23 August 2012 09:00, Jerry Vonau wrote: > On Wed, 2012-08-22 at 09:53 -0600, Daniel Drake wrote: >> Either way, I don't quite understand the situation involving the >> firmware here. (Maybe until now) there has been no driving need to >> upgrade firmware when upgrading OS releases - it can be done before, >> after, 3 weeks after, doesn't make a big difference. > > Yes it did at one point, way back when sparse support was first added to > the .zd files in order to gain the speed advantage offered the required > firmware must be installed first. We also wanted an easy way to get NANDblaster-compatible firmware out to all of our XOs in the field. As the first adopters of the XO-1.5, we had many units that could not receive a NANDblaster signal. We don't issue firmware updates very often at all. >> Or is there a >> reason I'm missing for why you go to special lengths to make sure the >> firmware upgrade is done first? >> > > After an OS upgrade we can't expect a teacher to boot each XO with an AC > adapter plugged-in when there maybe only one adaptor available for the > class or no AC at all because of the use of alternate charging methods. > I wonder how this is handled in other deployments that are using > solar-panels or hand cranks because there is no AC available. We have > chosen to have the firmware installed from a USB drive as we can disable > the AC check, and use the charge level of the battery to ensure there is > enough power present to ensure success with the updating processes with > our olpc.fth script. We use charging racks for classroom sets, not individual AC adapters. It is not practical to boot/use the XO while it is plugged in. Hence, firmware updates cannot occur if AC is required. Our workaround is to remove the AC check and institute a battery check. We understand that there are risks involved in this (e.g. the reported battery state may be different from the actual state), we decided that the benefits outweigh the risks. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Wed, 2012-08-22 at 09:53 -0600, Daniel Drake wrote: > On Tue, Aug 21, 2012 at 4:06 PM, Jerry Vonau wrote: > > While working with Australia, we have found the need to have the AC > > plugged-in for a firmware update while not requiring AC for a image > > upgrade to be problematic in the field. You can start an OS upgrade then > > run out of battery leaving a incomplete upgrade, while an AC adaptor may > > not always be available to use while your employing charging racks. We > > make our signed firmware available for download outside of the image, to > > enable the firmware to be installed from a USB drive before updating the > > OS. We disable the AC check and force a minimum 50% battery level before > > either actions can occur with our custom olpc.fth script which is part > > of our One Education USB[1] project. To my knowledge we have not bricked > > any XOs in the field using this method. > > Is this driven because your OS update process is not resilient to power > failure? > No, once upon a time the official OLPC upgrade process was not resilient to power failures[1][2]. > Either way, I don't quite understand the situation involving the > firmware here. (Maybe until now) there has been no driving need to > upgrade firmware when upgrading OS releases - it can be done before, > after, 3 weeks after, doesn't make a big difference. Yes it did at one point, way back when sparse support was first added to the .zd files in order to gain the speed advantage offered the required firmware must be installed first. > Or is there a > reason I'm missing for why you go to special lengths to make sure the > firmware upgrade is done first? > After an OS upgrade we can't expect a teacher to boot each XO with an AC adapter plugged-in when there maybe only one adaptor available for the class or no AC at all because of the use of alternate charging methods. I wonder how this is handled in other deployments that are using solar-panels or hand cranks because there is no AC available. We have chosen to have the firmware installed from a USB drive as we can disable the AC check, and use the charge level of the battery to ensure there is enough power present to ensure success with the updating processes with our olpc.fth script. Jerry 1. http://lists.laptop.org/pipermail/devel/2012-April/034836.html 2. http://dev.laptop.org/ticket/11776 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Tue, Aug 21, 2012 at 4:06 PM, Jerry Vonau wrote: > While working with Australia, we have found the need to have the AC > plugged-in for a firmware update while not requiring AC for a image > upgrade to be problematic in the field. You can start an OS upgrade then > run out of battery leaving a incomplete upgrade, while an AC adaptor may > not always be available to use while your employing charging racks. We > make our signed firmware available for download outside of the image, to > enable the firmware to be installed from a USB drive before updating the > OS. We disable the AC check and force a minimum 50% battery level before > either actions can occur with our custom olpc.fth script which is part > of our One Education USB[1] project. To my knowledge we have not bricked > any XOs in the field using this method. Is this driven because your OS update process is not resilient to power failure? Either way, I don't quite understand the situation involving the firmware here. (Maybe until now) there has been no driving need to upgrade firmware when upgrading OS releases - it can be done before, after, 3 weeks after, doesn't make a big difference. Or is there a reason I'm missing for why you go to special lengths to make sure the firmware upgrade is done first? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Tue, Aug 21, 2012 at 7:24 PM, James Cameron wrote: > On Tue, Aug 21, 2012 at 12:04:04PM -0600, Daniel Drake wrote: >> 2. Append the XO-1.75 device tree to the kernel image. > > We also hope to boot this same kernel on other hardware, so it might > be necessary to include multiple device trees in this kernel. While that is a valid consideration, it is not a foregone conclusion that we'll ship a single image for XO-1.75 and XO-4. TBH, I think it is a laudable, elegant goal, but the practicalities of getting XO-4 into production mean we have to consider very carefully whether we want to have the freedom that a separate build provides. > We might also version the device trees, so that "good" is easier to > define. Yes, please. As others have pointed out in internal communications, "best, accepted practice" in DT layout is likely to change over time. At least we can say: it is early days, and DT practices haven't settled yet. We have to have a means to version our DT, and perhaps ship a "DT I understand" with each kernel, as a fallback. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Tue, Aug 21, 2012 at 12:04:04PM -0600, Daniel Drake wrote: > 2. Append the XO-1.75 device tree to the kernel image. We also hope to boot this same kernel on other hardware, so it might be necessary to include multiple device trees in this kernel. > This is my favourite option - while we would have to duplicate the DT > (once in the firmware, once in the kernel), at least they can be > direct copies rather than two different approaches to maintain. > > (can the kernel be made to use this only when a "good DT" is > unavailable? Maybe the definition of "good DT" is hard to define - I'm > referring to the fact that we already ship a DT, but not one that can > be used to get the system on its feet in the absence of a board > file) We might also version the device trees, so that "good" is easier to define. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
On Tue, 2012-08-21 at 12:04 -0600, Daniel Drake wrote: > Hi, > > We want to follow the upstream direction of dynamically driving > hardware detection by the firmware-provided device tree, rather than > hardcoding a board file into the kernel. > > We have in-development kernel and firmware versions that make this > move, but we need to do this in a way that doesn't disrupt existing > users on upgrade. > > These are the possible scenarios: > new = whats currently in development, DT > old = whats currently shipped as stable, non-DT > > 1. New kernel, new firmware: this is the easy case - in this scenario > we upgrade both components and we know that they work together since > we wrote tham that way. > > 2. New firmware, old kernel: This currently will not boot, because the > new firmware boots with a new /chosen/bootpath value which is not > recognised by the initramfs shipped with the old kernel. > However, it is not clear that we do need to support this case: the > requirement of running a new firmware on top of an old software base > is not common. And the only option we'd have of fixing it is putting > nasty hacks in the firmware, so if the need does arise in future, we > could produce new firmware versions with the required hacks included. > > 3. Old firmware, new kernel: This is a case we definitely have to care > about. When system updates are done in the field, it is not guaranteed > that electricity will be available upon the reboot in order to install > the updated firmware. So we need to keep this case working. (We know > this is an issue because we've pushed OS updates dependent on new > firmwares before, then we had to revert that upon realising the field > difficulties). > While working with Australia, we have found the need to have the AC plugged-in for a firmware update while not requiring AC for a image upgrade to be problematic in the field. You can start an OS upgrade then run out of battery leaving a incomplete upgrade, while an AC adaptor may not always be available to use while your employing charging racks. We make our signed firmware available for download outside of the image, to enable the firmware to be installed from a USB drive before updating the OS. We disable the AC check and force a minimum 50% battery level before either actions can occur with our custom olpc.fth script which is part of our One Education USB[1] project. To my knowledge we have not bricked any XOs in the field using this method. Jerry 1. https://dev.laptop.org.au/projects/xo-au-usb/ > > So #3 is the only case that needs our special attention at the present > time. The issue here is that the old firmware does not present a > good-enough device tree to the kernel, and the new kernel does not > have the old/static XO-1.75 board definitions. The system won't boot - > some corruption appears at the bottom of the screen, and nothing > appears over serial. > > Ideally we want a solution for this that will hold for the long term - > i.e. its something we'd ship for considerable years to come, not only > just for the next release, to provide a direct upgrade path from the > software releases of today to any release of the future. > > Options include: > 1. Ship the static board file in the kernel, or maybe a cut down version of > it. > I'm not so keen on this - we'd have to keep the non-upstream kernel > code around forever. > > 2. Append the XO-1.75 device tree to the kernel image. > This is my favourite option - while we would have to duplicate the DT > (once in the firmware, once in the kernel), at least they can be > direct copies rather than two different approaches to maintain. > > (can the kernel be made to use this only when a "good DT" is > unavailable? Maybe the definition of "good DT" is hard to define - I'm > referring to the fact that we already ship a DT, but not one that can > be used to get the system on its feet in the absence of a board file) > > 3. Somehow detect this case and print a warning message. > Not so keen on this myself - expressing this in kid-friendly language > seems challenging, then there's internationalisation and so on. > > > Any thoughts or points that I'm missing? > Thanks > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
I do not have an XO-1.75. But with other XO models, I update firmware INDEPENDENTLY of updating the distribution, and update the kernel INDEPENDENTLY of updating the firmware or the distribution. Surely I am not alone in the world in doing so. If stable (old) kernels will not boot with development (new) firmware, I suggest adding two warnings to the new firmware: 1. Whenever the new firmware is flashed INDEPENDENTLY of the distribution, somehow insert a new "emit" step into the installation process, to emit the following message: "WARNING: This ROM q4z00 will not allow 12.0.0 or earlier releases to boot". Then the person doing the install will at least have been warned. 2. Add a new flag to every distribution that requires the new firmware. Whenever the new firmware is used to flash a distribution, if that distribution does not have that flag, refuse to perform that install, and have the new firmware emit: "ERROR: Install of File 21099o2 not supported." 3. Whenever a new distribution (requiring the new firmware) is flashed INDEPENDENTLY with the old firmware, the person doing the install would be left to recover on his own. The release notes for the new distribution should document what the person doing the installer would see (given such a situation) when he tries to boot the system - and should explain that the new firmware must be installed. Optionally the new distribution could have code added to it, so that when the boot process fails for lack of the DT - to tell the person doing the install that a new firmware must be installed in order to run that distribution. [If you are adding code to the new distribution, you might instead include a "basic" DT to allow the new distribution to boot anyway.] 4. Whenever someone installs a new kernel INDEPENDENTLY of the firmware and of the distribution, and the system subsequently does not boot -- TOO BAD. [The new release notes should warn that a "mismatch" __WILL__ render the system non-bootable.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Migrating XO-1.75 to device tree - upgrade considerations
daniel wrote: > Hi, > > We want to follow the upstream direction of dynamically driving > hardware detection by the firmware-provided device tree, rather than > hardcoding a board file into the kernel. > > We have in-development kernel and firmware versions that make this > move, but we need to do this in a way that doesn't disrupt existing > users on upgrade. > > These are the possible scenarios: > new = whats currently in development, DT > old = whats currently shipped as stable, non-DT > > 1. New kernel, new firmware: this is the easy case - in this scenario > we upgrade both components and we know that they work together since > we wrote tham that way. > > 2. New firmware, old kernel: This currently will not boot, because the > new firmware boots with a new /chosen/bootpath value which is not > recognised by the initramfs shipped with the old kernel. > However, it is not clear that we do need to support this case: the > requirement of running a new firmware on top of an old software base this is the case someone will be in if they install a new release, then re-install an old release. perhaps not something universally done, but is it really that "uncommon"? paul > is not common. And the only option we'd have of fixing it is putting > nasty hacks in the firmware, so if the need does arise in future, we > could produce new firmware versions with the required hacks included. > > 3. Old firmware, new kernel: This is a case we definitely have to care > about. When system updates are done in the field, it is not guaranteed > that electricity will be available upon the reboot in order to install > the updated firmware. So we need to keep this case working. (We know > this is an issue because we've pushed OS updates dependent on new > firmwares before, then we had to revert that upon realising the field > difficulties). > > > So #3 is the only case that needs our special attention at the present > time. The issue here is that the old firmware does not present a > good-enough device tree to the kernel, and the new kernel does not > have the old/static XO-1.75 board definitions. The system won't boot - > some corruption appears at the bottom of the screen, and nothing > appears over serial. > > Ideally we want a solution for this that will hold for the long term - > i.e. its something we'd ship for considerable years to come, not only > just for the next release, to provide a direct upgrade path from the > software releases of today to any release of the future. > > Options include: > 1. Ship the static board file in the kernel, or maybe a cut down version of > it. > I'm not so keen on this - we'd have to keep the non-upstream kernel > code around forever. > > 2. Append the XO-1.75 device tree to the kernel image. > This is my favourite option - while we would have to duplicate the DT > (once in the firmware, once in the kernel), at least they can be > direct copies rather than two different approaches to maintain. > > (can the kernel be made to use this only when a "good DT" is > unavailable? Maybe the definition of "good DT" is hard to define - I'm > referring to the fact that we already ship a DT, but not one that can > be used to get the system on its feet in the absence of a board file) > > 3. Somehow detect this case and print a warning message. > Not so keen on this myself - expressing this in kid-friendly language > seems challenging, then there's internationalisation and so on. > > > Any thoughts or points that I'm missing? > Thanks > Daniel > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Migrating XO-1.75 to device tree - upgrade considerations
Hi, We want to follow the upstream direction of dynamically driving hardware detection by the firmware-provided device tree, rather than hardcoding a board file into the kernel. We have in-development kernel and firmware versions that make this move, but we need to do this in a way that doesn't disrupt existing users on upgrade. These are the possible scenarios: new = whats currently in development, DT old = whats currently shipped as stable, non-DT 1. New kernel, new firmware: this is the easy case - in this scenario we upgrade both components and we know that they work together since we wrote tham that way. 2. New firmware, old kernel: This currently will not boot, because the new firmware boots with a new /chosen/bootpath value which is not recognised by the initramfs shipped with the old kernel. However, it is not clear that we do need to support this case: the requirement of running a new firmware on top of an old software base is not common. And the only option we'd have of fixing it is putting nasty hacks in the firmware, so if the need does arise in future, we could produce new firmware versions with the required hacks included. 3. Old firmware, new kernel: This is a case we definitely have to care about. When system updates are done in the field, it is not guaranteed that electricity will be available upon the reboot in order to install the updated firmware. So we need to keep this case working. (We know this is an issue because we've pushed OS updates dependent on new firmwares before, then we had to revert that upon realising the field difficulties). So #3 is the only case that needs our special attention at the present time. The issue here is that the old firmware does not present a good-enough device tree to the kernel, and the new kernel does not have the old/static XO-1.75 board definitions. The system won't boot - some corruption appears at the bottom of the screen, and nothing appears over serial. Ideally we want a solution for this that will hold for the long term - i.e. its something we'd ship for considerable years to come, not only just for the next release, to provide a direct upgrade path from the software releases of today to any release of the future. Options include: 1. Ship the static board file in the kernel, or maybe a cut down version of it. I'm not so keen on this - we'd have to keep the non-upstream kernel code around forever. 2. Append the XO-1.75 device tree to the kernel image. This is my favourite option - while we would have to duplicate the DT (once in the firmware, once in the kernel), at least they can be direct copies rather than two different approaches to maintain. (can the kernel be made to use this only when a "good DT" is unavailable? Maybe the definition of "good DT" is hard to define - I'm referring to the fact that we already ship a DT, but not one that can be used to get the system on its feet in the absence of a board file) 3. Somehow detect this case and print a warning message. Not so keen on this myself - expressing this in kid-friendly language seems challenging, then there's internationalisation and so on. Any thoughts or points that I'm missing? Thanks Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
