khulat
Posts: 105
Joined: Sun Feb 12, 2012 9:43 pm

Re: config.txt

Tue Feb 14, 2012 1:38 pm

NAB said:

Indeed. Again, you misunderstand. For the school to make this choice, they need to be fully informed of the options and implications and also have a very simple way of acting on that choice.
Bear in mind that 'the school' may not be computer literate and you certainly can't assume that they trawl through this forum. The kids, on the other hand...


You are quite right, the way i envisioned it there would be the SD Card already in the Pi that would set the "warranty is safe" bit upon first boot. Then there could be one of those Red warning cards that tells the person who is unpacking that they should boot once to be absolutely sure that their warranty can't be voided. And then a link to a more thorough explanation. I think that should be enough to make as sure as possible that the school is informed of the pitfalls.

User avatar
kyndair
Posts: 7
Joined: Mon Jan 09, 2012 10:09 pm

Re: config.txt

Tue Feb 14, 2012 2:08 pm

rurwin said:


kyndair said:


To modify my earlier suggestion, include the non overclock statement in the config commented out, with a comment next to it saying that if it is uncommented the board wil not be capable of being overclocked in the future, this will allow school techs setting up the schools equipment to set the otp bit for the school equipment.


No. Because a pupil could bring his own RaspPi into school, insert the school's SD card for his lesson, and then never be able to overvolt his card again. You can tell them not to set the bit on all card images, but I bet they will anyway.

I think you need to offer this at the level of the shop. Sell schools RaspPis with the disable bit already set. If that means that us hackers never get their hands on an overvoltable board then too bad.

The alternative is to offer that image which sets the bit. In most cases the incoming RaspPis will go through some sort of IT department, even if it is just Mr Smith in his spare periods. But it should also be possible for Mr Smith to tell which boards have the disable bit set, and which boards have already been overvolted.



If the otp bit has been set for not allowing overvoltage it doesn't matter what the child does it's a one time deal, shutting down all clocking mods would not helpful as kids should have the chance to clock and see what happens to stability etc. the kids being able to get at the hardware side of this is all part of the learning

nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: config.txt

Tue Feb 14, 2012 3:29 pm

My opinion:

Enabling overvolting should NOT be tied to the SD card.

Solution:


The configuration of overvolting can still be in config.txt, but none of the options will work unless an "enable_overvolting" OTP bit is set.
In order to set this bit, one would run a linux program that the RPI foundation would write.

Something like this:RPI:~ # ./enable_overvolting
WARNING: Use at your own risk. Enable overvolting will void the warranty of your raspberry pi.
This program will set a OTP bit that will enable overvolting and CANNOT be unset.

To continue please type. "VOID_WARRAUNTY"
>VOID_WARRAUNTY
................. enable_overvolting OTP bit has been set.
Use of overvolting options in config.txt is now enabled.
Have a nice day.


Perhaps you could also have a disable_overvolting executable to permanently disable overvolting.

The point is that one shouldn"t be able to accidentally set any OTP bits by having the wrong SD card.

nelson
Posts: 38
Joined: Sat Dec 17, 2011 3:43 am

Re: config.txt

Tue Feb 14, 2012 4:41 pm

The solution presented by nullstring may be a good compromise

User avatar
psergiu
Posts: 223
Joined: Mon Nov 07, 2011 8:36 am
Location: TX, U.S.A. (was: RO, E.U.)
Contact: Website

Re: config.txt

Tue Feb 14, 2012 6:40 pm

Alternate solution - on the next revisions of the board, sacrifice a GPIO Pin for a 0 ohm SMD resistor that has to be unsoldered in order to enable voltage changes. Then if the resistor is removed and voltage changes are used in config.txt, burn the OTP fuse.

This way kids cannot do evil just by editing config.txt. And overclocking geeks can unsolder-it themselves, ask a friend to do it or go to a mobile phone repair shop.

A "remove resistor" solution is better than "solder a jumper between two pads" as those pads can be shorted with a bent paperclip without leaving a trace. Soldering the SMD resistor back neatly enough so it looks like the original job by the pick-and-place machine is hard. And the OTP fuse is already blown anyway.

hippy
Posts: 6299
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: config.txt

Tue Feb 14, 2012 6:46 pm

nullstring said:

The configuration of overvolting can still be in config.txt, but none of the options will work unless an "enable_overvolting" OTP bit is set.
In order to set this bit, one would run a linux program that the RPI foundation would write.
That sounds reasonable and there needs to be some failsafe that helps protect a person who owns two R-Pi, one they are prepared to sacrifice warranty on and one not, from the effects of booting an over-volt inducing SD Card on the wrong one by accident.

However ... If OTP bits can be set from a Linux program does that not mean all OTP bits could be set the same way; another vector for malicious programs to blow the "you've lost warranty" fuse.

nullstring
Posts: 178
Joined: Sun Oct 02, 2011 3:05 pm

Re: config.txt

Tue Feb 14, 2012 9:31 pm

hippy said:


nullstring said:


The configuration of overvolting can still be in config.txt, but none of the options will work unless an "enable_overvolting" OTP bit is set.



In order to set this bit, one would run a linux program that the RPI foundation would write.


That sounds reasonable and there needs to be some failsafe that helps protect a person who owns two R-Pi, one they are prepared to sacrifice warranty on and one not, from the effects of booting an over-volt inducing SD Card on the wrong one by accident.

However ... If OTP bits can be set from a Linux program does that not mean all OTP bits could be set the same way; another vector for malicious programs to blow the "you've lost warranty" fuse.


Keep in mind, the malicious program would need to run as root.

It'll be hard, no matter what you do, to keep someone from voiding the warranty when they have root.

User avatar
Chromatix
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki

Re: config.txt

Tue Feb 14, 2012 10:12 pm

And if it is available from root, then it's still possible to make an SD card that voids the warranty - although it is slightly less "script kiddie" territory since it requires more than just editing a text file.  That's a good thing.

Ultimately however, you have to look at what anyone might get out of doing such a thing.  There are a few aspects to this:

1) Kid overclocks/overvolts his own R-Pi for better performance, and bakes these settings into his usual card.  This card is then used to boot a school R-Pi briefly (10 minutes) for a show-and-tell session - thus accidentally overclocking/overvolting that board.  Since people are used to overclocking settings being in the CMOS RAM, not the card, this is entirely plausible.

Should the warranty bit be blown?  If not, should the overclock "take"?  With an OTP bit for *permitting* overvolting, or with one blown for *preventing* it, there is no accident, the warranty remains intact, and the board may or may not boot due to overclocking beyond stable limits.  One could say that if overvolting is called for but is not permitted, the overclock settings should be ignored.

2) Kid makes a malicious card which unlocks the OTP bit (if necessary) and overvolts the R-Pi, just to blow the warranty bit, and makes the rounds with it, booting each board for just a few seconds.  Nobody knows that this has happened, since all the boards run perfectly fine and at normal speed when booted from normal cards.

But what's the motive?  If nobody knows, it's difficult to justify doing this for bragging rights or for revenge.  Even sabotage is unlikely, since an R-Pi is unlikely to fail immediately or eventually due to a few seconds' running in an overclocked condition.  If one or a few *do* fail immediately, there is a fairly good chance that the perp can be identified and appropriate action taken.

Even so, a prevent-overvolting OTP bit could successfully prevent such an attack.  I just don't entirely see why it is necessary.

3) Kid makes a malicious Trojan card which blows the prevent-overvolting OTP bit.  He then convinces other kids to boot the card, based perhaps on some "cool demo" (which he need not have written himself).  Result: other kids' *personal* R-Pis are no longer capable of overvolting, and power users might find that the overclock settings on their usual cards are no longer stable.

I *can* see a motive for this:  jealousy, hence sabotage.  One kid's R-Pi consistently runs better than another because he's not afraid to play with the overclock settings, and maybe he got a chip slightly better than average by chance.  Other kid wants to cut him down to size...

Overall I therefore suspect that the "prevent overvolting" bit would be more harmful than the "allow overvolting" one.
The key to knowledge is not to rely on people to teach you it.

User avatar
rurwin
Forum Moderator
Forum Moderator
Posts: 4258
Joined: Mon Jan 09, 2012 3:16 pm
Contact: Website

Re: config.txt

Tue Feb 14, 2012 11:43 pm

But if the allow-overvolting bit is set, the software would refuse to set the prevent-overvolting bit, and vice-versa.

So the kid can stop other kids from overvolting, but only before they thought of doing it.

User avatar
Jessie
Posts: 1754
Joined: Fri Nov 04, 2011 7:40 pm
Location: C/S CO USA

Re: config.txt

Wed Feb 15, 2012 1:33 am

Anyone committed this info to the wiki yet?  I will do it tomorrow if it has not, I just don't want to duplicate any work.  Warranty issues are valuable to some, and overclocking is usefull to others.

Edit: I found the entry and edited it some.

User avatar
Jessie
Posts: 1754
Joined: Fri Nov 04, 2011 7:40 pm
Location: C/S CO USA

Re: config.txt

Wed Feb 15, 2012 8:05 pm

Here is another question about over-volting.  Is the config.txt file the only way to over volt?  Lets say I want to push more than 1.4V can I replace a resistor somewhere or is the SOC internally regulated?

I'm only asking because with the cost of these boards being so low some of us are going to want to push them as far as possible for some of our applications.  I personally will take one to the limits just for the hell of it after I have a few on hand.

Piw32
Posts: 82
Joined: Sun Dec 04, 2011 8:46 am

Re: config.txt

Thu Feb 16, 2012 9:00 pm

Do you realize you are talking about warranty on a $35 item ?

I'm not rich, but if my Pi fails i will not make a package, go to the post office, pay overpriced shipping rate, send it back overseas and claim for warranty…

It will more likely be destroyed by contacting it with paperclips, scissors or other metallic parts lying on your desk, than overvoltage.

And usually, things tend to fail a week after the warranty period has expired...

User avatar
abishur
Posts: 4477
Joined: Thu Jul 28, 2011 4:10 am
Location: USA
Contact: Website

Re: config.txt

Thu Feb 16, 2012 9:12 pm

Piw32 said:


Do you realize you are talking about warranty on a $35 item ?



Of course!  Well, more accurately we're also talking about a warranty on a $25 item. Sadly in our over lawyered societies (no offense Liz ) disclaimers like these must be stated or else someone will come back saying "you didn't warn me now I'm suing you for millions!"
Dear forum: Play nice ;-)

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: config.txt

Thu Feb 16, 2012 11:15 pm

Maybe the thing should come with (in big bold, unmistakable letters) the standard "software warranty" - i.e., no warranty at all.  I.e., "There is no warranty, expressed or implied, blah, blah, blah.  No assertion of merchantability or suitability for any specific purpose, blah, blah, blah.

As a friend of mine put it, the warranty (in the case of software) always boils down to:

It is (or at least at one point was) a floppy disk.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

rpt
Posts: 51
Joined: Tue Jan 31, 2012 3:09 pm

Re: config.txt

Fri Feb 17, 2012 9:03 am

Joe Schmoe said:


Maybe the thing should come with (in big bold, unmistakable letters) the standard "software warranty" - i.e., no warranty at all.  I.e., "There is no warranty, expressed or implied, blah, blah, blah.  No assertion of merchantability or suitability for any specific purpose, blah, blah, blah.


Not possible within the UK (thanks to the Sale of Goods Act) and probably not possible throughout the EU.

NAB
Posts: 32
Joined: Wed Sep 14, 2011 6:52 pm

Re: config.txt

Fri Feb 17, 2012 9:12 am

Piw32 said:


Do you realize you are talking about warranty on a $35 item ?


No, we're not. In the case of a large school, we may be talking warranty on fifty or more $35 items. I can only speak from my own experience, but if during the procurement process we found out that the units were effectively unwarranted, we would think long and hard about whether they should be purchased or not.

The important thing is not the warranty in itself, nor is it the fact that a pupil could remove the warranty simply - it's more the whole picture. How could we trust a product which can be so easily 'broken'  and how can we recommend this product to the children's parents when it may break quickly? (I use the word 'break' from the point of view of a non-techy holding the purse strings - you and I both know that overvolted doesn't mean broken!)

Anybody looking at this argument from an "I'm alright Jack" or "Warranty on one $35 unit" simply doesn't see the bigger picture - this isn't about you. It isn't about single developers. It is about organisations who would invest (or recommend the investment of) significant (to them) amounts of cash in RPi hardware.

Nicholas

Chris.Rowland
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm

Re: config.txt

Fri Feb 17, 2012 10:12 am

If some kid took an axe to your car would you expect the damage to be covered by the guarantee?  Or the Sale of Goods Act?

Of course not.

So why should the RPF be responsible for malicious damage?

Chris

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: config.txt

Fri Feb 17, 2012 10:18 am

rpt said, in response to my somewhat facetious suggestion of the inclusion of (what I consider) the "standard" software warranty:


Not possible within the UK (thanks to the Sale of Goods Act) and probably not possible throughout the EU.



Very interesting.  Always nice to learn about other, more advanced cultures.
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

NAB
Posts: 32
Joined: Wed Sep 14, 2011 6:52 pm

Re: config.txt

Fri Feb 17, 2012 10:22 am

Chris Rowland said:


If some kid took an axe to your car would you expect the damage to be covered by the guarantee?  Or the Sale of Goods Act?

Of course not.

So why should the RPF be responsible for malicious damage?


Nobody is suggesting this.

To extend your example, what if the car was labeled "Fill up with petrol or diesel. Using petrol will make the car go faster but will void the warranty. Only we will be able to tell if somebody's put petrol in the car". Now lend that car to twenty of your closest friends....

Nicholas.

Chris.Rowland
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm

Re: config.txt

Fri Feb 17, 2012 10:48 am

And it's still not the fault of the company, they have no control over how it's abused.

Having a feature to protect themselves from guarantee claims when something has been operated outside it's specification doesn't seem unreasonable.

Maybe there's such a thing as too much information.

Chris

NAB
Posts: 32
Joined: Wed Sep 14, 2011 6:52 pm

Re: config.txt

Fri Feb 17, 2012 10:52 am

Chris Rowland said:


And it's still not the fault of the company, they have no control over how it's abused.

Having a feature to protect themselves from guarantee claims when something has been operated outside it's specification doesn't seem unreasonable.


On the contrary, when the company provides a mechanism for this abuse, is aware of the consequences of the abuse, doesn't provide any protection from the abuse and doesn't provide any indication that the abuse has occurred, I'd say they are very liable. Of course, a judge may disagree.

Nicholas.

Chris.Rowland
Posts: 239
Joined: Thu Jan 12, 2012 5:45 pm

Re: config.txt

Fri Feb 17, 2012 11:06 am

As I said, too much information. The vast majority of companies would not publish this information - and the FUD that it's caused shows why.

Is it the RPF who has provided the information?  It's certainly not been done so in any official manual and I think that even if it was putting it in a section marked "this will invalidate your guarantee" would be enough.

Chris

NAB
Posts: 32
Joined: Wed Sep 14, 2011 6:52 pm

Re: config.txt

Fri Feb 17, 2012 11:14 am

Chris Rowland said:


As I said, too much information. The vast majority of companies would not publish this information - and the FUD that it's caused shows why.


Whether other organisations would publish this information or not is irrelevant. The fact is that RPF have. With my public-sector/corporate hat on, this is a geniune concern, not FUD.


Is it the RPF who has provided the information?


Yes.


It's certainly not been done so in any official manual


There are no official manuals.


and I think that even if it was putting it in a section marked "this will invalidate your guarantee" would be enough.


Again, you are viewing this from a one-man, one-board perspective. From this point of view, I believe you are quite right.

Think, however, of a school where the boards will be used by all the pupils and will be managed by a technician who doesn't have a clue about computers.

I think this argument isn't going anywhere, so I'm going to withdraw at this point.

Nicholas.

User avatar
RaTTuS
Posts: 10506
Joined: Tue Nov 29, 2011 11:12 am
Location: North West UK
Contact: Twitter YouTube

Re: config.txt

Fri Feb 17, 2012 11:29 am

Who can tell how the education versions will be initialised ... only the foundation, but the ones available to us from the 1st 2nd 3rd versions can have this bit set [or unset as you see fit]
How To ask Questions :- http://www.catb.org/esr/faqs/smart-questions.html
WARNING - some parts of this post may be erroneous YMMV

1QC43qbL5FySu2Pi51vGqKqxy3UiJgukSX
Covfefe

Joe Schmoe
Posts: 4277
Joined: Sun Jan 15, 2012 1:11 pm

Re: config.txt

Fri Feb 17, 2012 11:48 am

NAB said:



Think, however, of a school where the boards will be used by all the pupils and will be managed by a technician who doesn't have a clue about computers.


But is that really the model?  You're thinking of the RPi(s) as a school resource, like the A/V equipment (or the gym equipment).   I think, given the goals of the foundation (which is to make computers something more tangible - more a part of the individual) and the price, that the model is more like a jacket - something you have to privately purchase and privately maintain as part of the school experience.

Also note, I am aware that the focus here is on elementary education, but another analogy that keeps coming to my mind is that of college textbooks.  In elementary and secondary education, the textbooks are provided by the school; as a result of this, it was a shock to me when I arrived at University and found that I was expected to shell out a couple hundred bucks each quarter for textbooks (items that would essentially be useless to me after the term).  But that's the way we should be looking at the Rpi (I think).
And some folks need to stop being fanboys and see the forest behind the trees.

(One of the best lines I've seen on this board lately)

Return to “General discussion”