Ticket #341 (Fixed)Sat Apr 13 13:37:24 UTC 2013
Raspberry Pi CMOS incorrectly written back on ROM change
| Reported by: | Theo Markettos (89) | Severity: | Major |
| Part: | RISC OS: General | Release: | |
| Milestone: | Status | Fixed |
Details by Theo Markettos (89):
Consider this:
1. I boot up a Raspberry Pi in the normal way using the ROM on SD card
2. I download a new ROM and replace the old one in !Boot.Loader
3. I shutdown the machine and reboot
What’s happening is that shutdown is replacing the CMOS part of the new ROM with the CMOS settings for the old ROMs. This means if the CMOS layout has changed, you get the old values in the wrong places. Depending on the CMOS values, it may be this causes a boot failure. If you instead pull the power and not shutdown, the correct new CMOS settings are applied.
Consider also what would happen if the ROM size were to increase – presumably the CMOS might get saved in the middle of the new ROM, overwriting whatever code that was there. The machine would either crash or not boot at all.
This means in-place ROM upgrades are vulnerable to be trampled upon. Perhaps a solution would be to CRC the ROM file before writing, and only write CMOS to a ROM with the same CRC as the ROM we’re currently running?
Changelog:
Modified by Dick Tanis (1648) Sat, April 13 2013 - 15:08:25 GMT
I agree that things could go wrong when the CMOS-layout is changed with a new ROM but it would not be nice if I lose my settings (like timezone, territory, DST, Wimp settings) every time I update the ROM. So it would be nice if there’s some tool going to be developed which could export/import the old CMOS-setting to new ROM without having to worry that some old settings are giving problems with the new ROM.
Modified by Sprow (202) Tue, April 16 2013 - 06:56:10 GMT
The last 2 paragraphs of concern are already dealt with – the OS carefully searches for the settings table each time before writing, so if the ROM is changed under its feet it doesn’t save over anything it shouldn’t.
To the first point, this is not a new use case: consider saving your settings & shutting down, unplugging the RISC OS 3.50 ROMs and plugging in RISC OS 3.60, boot back up again.
The CMOS allocations scheme ensures that locations have the same or similar meaning where at all possible (though often Acorn would just bail out and insist on a DELETE-power-on).
The most common difference between versions though is that the module order has changed as both the CMOS frugal bits and the language number are stored as absolute module numbers (rather than, say, the configured filing system which is kept as the FS number). Fortunately, this mapping is simple and event driven (ie. you know it will happen, and you know the mapping from old to new) – I’ve written an installer for IOMD that does the frugal bits already.
I suspect similar functionality could be added to Packman (you could also post fixup during the next boot up, but ideally want to do it on shutdown incase some unplugged module stops you from booting!).
Modified by Theo Markettos (89) Wed, April 24 2013 - 17:17:50 GMT
- Status changed from Open to Fixed
I’ve implemented a fix in the RaspberryPi-ROM package (version 5.19.20130320.053234-7) that is now in the raspberrypi-testing repository. It:
Checks to see if the current configured language is TaskManager (which is meaningless). If so it:
1. Configures the language as Desktop
2. Shuffles the unplug flags to fit the new RC8 format
and then deletes itself.
Checking the configured language is a bit hackily-specific to this case, so one idea to make this easier in future is to put the build date/revision/CVS tag into CMOS somehow (eg the 16 bytes where the clock normally lives) so it’s possible to distinguish them.
