You are correct, but Pi2 runs at a higher voltage by default which meant that force_turbo was incorrectly setting the "warranty" bit. That was unintended.
So, what we've agreed to do is to no longer treat bit 24 of the board revision as the warranty warranty bit on Pi 2.
The latest rpi-update will now set bit 25 when a real warranty condition arises (e.g. force_turbo=1 *and* over_voltage > 0)
If bit 24 is currently set, then don't worry, it will be ignored. Bit 25 is the new Pi 2 warranty bit.
Pi1 will remain as it did with bit 24 being the warranty bit.
Thanks for the clarification on this. I was confused about what appeared to be the warranty bit appearing on the Pi2 when I hadn't seen this occur on my model Bs.
I have one further question. I want to have a card image that will boot and work on either a model B or a Pi2. i have an image that I've been working on that has the following config.txt:
Code: Select all
#uncomment to overclock the arm. 700 MHz is the default.
# for more options see http://elinux.org/RPi_config.txt
Will this have any other unexpected consequences, apart from setting bit 24 on the Pi2 (as discussed)? Will the arm_freq of 840 simply be ignored by the Pi2, for example, and it will continue to run at the default 900MHz?
Also, i've discovered that loading the peripheral modules for spi etc using the device tree is not equivalent to loading the old way... the drivers loaded using device tree seem to lead to some performance issues compared to the old drivers. Haven't investigated closely enough to figure out what is happening, but the take home is that the device_tree drivers may not perform as expected when compared to the no device-tree drivers. So in the meantime i've simply disabled the device_tree loading.