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

Re: config.txt

Fri Feb 17, 2012 11:58 am

RaTTuS said:  


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]



I can't quite tell (from following all the back-and-forth in this thread) if it is or isn't the case that it is possible (in the current context)  to produce (at the factory level) a "safe" version.  By a "safe" version, I mean one where you can't "over-volt" it - i.e., where you can't break it via software.

If it is possible to factory-produce a safe version, then it seems clear to me that that is the only sensible solution to the problem raised in this thread.  I.e., the solution is to factory-produce two versions of the product - one safe and warrantied - the other not (either safe or warrantied).  Then let the consumer decide which one to buy.

If it is not possible (i.e., because literally all the logic is in the SD card and someone can always produce an unsafe SD card, stick it in the machine and boot it), then the (largely social, not technical) issues raised in this thread are quite real.
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)

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

Re: config.txt

Fri Feb 17, 2012 12:34 pm

I think where we are at the moment is:

Current Situation:

One OTP fuse that voids warranty.

RPF Suggested Solution:

A second OTP fuse that stops the warranty being broken

Community Suggested Solution

A third OTP fuse that stops the second one being activated

It would be fairly trivial to have a program activate on first start-up which brought up a menu:


This device may be configured to use increased voltage. Doing so would void the warranty. For this reason it is possible to forbid this device from ever being so configured. This is a one-time operation that can not be undone. You may also ensure that this device is always allowed to be configured to use increased voltage. That is also a one-time operation that can not be undone.

These operations are optional. Either one may be carried out now, at any time in the future or never. You do not need to choose one now, or ever.

Whichever option you choose or do not choose, your warranty will be safe unless this device is ever configured to use an increased voltage.

1. Forbid over-volting, protecting the warranty

2. Ensure over-volting will always be allowed

3. Do not do either

Choice [3] : _


That would allow schools to do it as a matter of course, and individuals to not do it or to ensure their freedom. It does not need to be done in the factory.

It is very important that the GPU software refuses to blow both fuses. If one is already set then any attempt to blow the other must fail. Then there can be a program on the standard SD card that can instruct the GPU to blow either fuse; it doesn't have to be a privileged operation, and so it does not have to be done by the factory. And as someone said, it only matters to schools, individuals probably would not bother invoking the warranty.

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

Re: config.txt

Fri Feb 17, 2012 12:47 pm

I believe that it does have to be done at the factory (and thus for there to be two versions marketed), for social/operational (not technical) reasons.  But I choose not to defend my position further at this time.

I agree with most of the rest of what you say.
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)

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

Re: config.txt

Fri Feb 17, 2012 1:29 pm

We will have to agree to disagree then.

But if it is to be done in the factory, then my vote would be to disable it on all boards. It is not worth the extra cost, and it provides nothing to the core market. Very few hobbyists will ever over-volt, no HTPC/router/server users will over-volt, and schools certainly will not.

This has to be decided now. Otherwise, in a very few days time there will be 10,000 binary blobs that can void a warranty, out in the wild. The horse will have left the building and it will be pointless locking the door.

User avatar
mkopack
Posts: 242
Joined: Mon Nov 07, 2011 8:46 pm

Re: config.txt

Fri Feb 17, 2012 2:57 pm

Honestly, the simplest solution is just don't support the overvolting at all....

If it's going to cause this much headache, don't support it! If you REALLY want a faster device, go buy a faster device!

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

Re: config.txt

Fri Feb 17, 2012 3:29 pm

Well, the problem (to use another animal metaphor) is that the cat's already out of the bag.

Which leads nicely into my next area of discussion.  It is one thing for us out here in the peanut gallery to endlessly debate this subject, but I wonder what the official position on it is.  What I am getting at is: Surely, the wheels at the foundation foresaw (to at least some degree) what would happen if (when) dom released the demon into the wild.

So, they must have anticipated this issue - I'm curious what their position on it all is.
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)

User avatar
hayesey
Posts: 78
Joined: Mon Nov 28, 2011 12:46 pm
Location: Manchester, England

Re: config.txt

Fri Feb 17, 2012 3:58 pm


But if it is to be done in the factory, then my vote would be to disable it on all boards. It is not worth the extra cost, and it provides nothing to the core market. Very few hobbyists will ever over-volt, no HTPC/router/server users will over-volt, and schools certainly will not.


I agree and was already thinking this when reading earlier posts before getting to this one.

I don't think an extremely small percentage of potential customers wanting to use the Pi outside it's designed limits is enough of a reason to build such a big risk into all devices.  I could see this being a good reason for the education sector to reject the product.  It's not a problem for a person having one or two boards (if you break it just buy another) but when the education sector as a whole has surely got to be thinking in quantities of hundreds of thousands, then it is a serious issue.

I don't like this idea of pupils being expected to purchase their own devices as a solution.  I'm sure many will do this anyway but I don't think computer science education should be limited to the people who can afford the hardware or who's parents actually care enough about their child's education to buy one.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23686
Joined: Sat Jul 30, 2011 7:41 pm

Re: config.txt

Fri Feb 17, 2012 4:59 pm

Joe Schmoe said:


Well, the problem (to use another animal metaphor) is that the cat's already out of the bag.

Which leads nicely into my next area of discussion.  It is one thing for us out here in the peanut gallery to endlessly debate this subject, but I wonder what the official position on it is.  What I am getting at is: Surely, the wheels at the foundation foresaw (to at least some degree) what would happen if (when) dom released the demon into the wild.

So, they must have anticipated this issue - I'm curious what their position on it all is.


I'll try and find out the official position.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

drgeoff
Posts: 9814
Joined: Wed Jan 25, 2012 6:39 pm

Re: config.txt

Fri Feb 17, 2012 5:28 pm

Joe Schmoe said:


Well, the problem (to use another animal metaphor) is that the cat's already out of the bag.

Which leads nicely into my next area of discussion.  It is one thing for us out here in the peanut gallery to endlessly debate this subject, but I wonder what the official position on it is.  What I am getting at is: Surely, the wheels at the foundation foresaw (to at least some degree) what would happen if (when) dom released the demon into the wild.

So, they must have anticipated this issue - I'm curious what their position on it all is.


In accordance with the "conspiracy or cock-up" rule my guess is that they hadn't thought this one through.  At least not to the depth discussed here.  :-)

mole125
Posts: 228
Joined: Tue Jan 10, 2012 2:01 pm

Re: config.txt

Fri Feb 17, 2012 6:17 pm

The thing people are missing is that in the UK/EU you can't actually void a warranty.

You can use a device outside its intended operating parameters and the company isn't liable for damage resulting from this usage, but they are still liable for unrelated defects in the product.  So if you overvolt it and a diode burns out then the foundation wouldn't be liable. If a solder joint fails and a socket starts to fall off then the foundation would still be liable. Similarly if there was a batch of defective diodes and you could show that there was a clear pattern of that diode failing then the foundation would be liable if you showed that you were having the same fault regardless of whether you over-clocked it. In this scenario you may have to prove on the balance of probabilities that you are experiencing that fault and not a different one caused by the over-volting (which if the bit is blown is the most likely explanation). Of course proving this would require some professional evidence to say why it failed which is likely to cost more than $35.

It's not unusual that devices have these type of protection, the classic example is mobile phones which now have water detectors in them to allow detection of potential water damage.

I'd also point out is that a warranty is not quite the same as a guarentee, it only covers defects in the quality of the product not accidental damage. I'd be much more concerned in school of theft and accidental damage (knocked on floor, mishandled, foreign objects shoved in sockets etc) than malicious attempts to over volt them.

Another thing to factor in is that the foundation have this ability to detect overvolting and have a basis to argue against warranty repairs, it doesn't provide an indication of how rigorously they will apply the policy - I'd expect that schools would be given more reasonable doubt and leniency than repeat private warranty claim offenders.

jacklang
Posts: 166
Joined: Thu Aug 04, 2011 10:59 am

Re: config.txt

Fri Feb 17, 2012 6:21 pm

You are right we had not discussed this aspect.

Bear in mind that this is a development release and we do not warranty misuse, any more than say warranty return after drilling a hole through the board or connecting it directly to the 240v mains

When we come to the educational release we will look again if its still a problem. It may be easier to change the terms of the warranty.

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

Re: config.txt

Fri Feb 17, 2012 6:31 pm

Hrm.. I think you guys are making this too complicated.

I still like my solution: Only allow someone to set the OTP via a linux program.


Removes any possibility of accidentally voiding warranty.
Students are known to be malicious, but really, it's a $25 item. There is no way a student is going to go and overvolt every single RPI. It's more much likely that they will break one in another way.
In the phone community, people could easily release binaries that would brick a person's phone... Except they don't.. This would be the same thing.. No one is going to release a distro, etc. that maliciously sets this OTP without someone's knowledge.

Also, an HTPC user may in fact overvolt their RPI when pursuing a smoother XBMC experience. I know I may.

Therefore, I think that it would be best:


One OTP for overclocking.
Set in a way that prevents it from being accidentally set. (Therefore, it should be enabled outside of config.txt)

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

Re: config.txt

Fri Feb 17, 2012 6:41 pm

I just got another idea. Does each device have it's own serial number?

In that case, you could make it so that a person can only overvolt their PI, if a certain setting on the config.txt has the PI's serial number in it.

Something like this:

#WARNING: This option will set an OTP bit that will void the RPI warranty and it done at YOUR RISK ONLY
#To enable overvoltage, please put your RPI serial number on this line.
#over_voltage_enable=1234567890 

This way if someone uses another person's SD card, the number will be wrong and the option will not be enabled.

If you really wanted, to you could also use public-key cryptography to make it so that you had to get a special number from the RPI foundation themselves in order to enable it.

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

Re: config.txt

Fri Feb 17, 2012 8:15 pm

NAB said:


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


Each day schools restaurants "invest" similar amounts of money into meals, half of them end up being dumped into the trashbin without any concern.

50 Pis at $25 = $1250 (per x years)

1000 meals at $3.5 = $3500 per day

so buy those Pis and "invest" into quality food wich is actually eaten.

poplap
Posts: 28
Joined: Thu Feb 23, 2012 12:48 am

Re: config.txt

Thu Feb 23, 2012 1:11 am

I was reading the thread and i find it very interesting. And thanks for all the information.

It come to my attention that this could all be fix by means of the firmware.

Assuming this over-volt function is enabled by the firmware and that some could flash this firmware.

Would it not be possible to sell the RPi with firmware that has over-volting disabled and then offer firmware that can flash it to enable over-volting? With a clear warning what may happen.

This could also be secured by having the program used to flash the RPi generate a random code that is required to over-volt the RPi.

I can see why it would be a good idea to lock it down for school, i would be the one trying to push the RPi limits in class (if i didnt know about the warranty thing ). I would like to try it with my own (maybe be get some extreme cooling setups for it).

But i also dont think that it should be limited ether, i can see a lot of people wanting to overclock and maybe even over-volt this to run some of the heavier DIY applications that i hear people wishing to try.

Just my .02

laszlo
Posts: 25
Joined: Thu Jan 26, 2012 6:03 pm

Re: config.txt

Thu Feb 23, 2012 3:29 am

I didn't even know there would be a warranty on this..

It would probably be good to just do away with anything that's permanent, but even if they came out and announced that they canned the OTP-bit idea, nobody would believe it.

By the way, thus far the foundation people have been pretty 'nice'.. I'm not suggesting that they shouldn't be criticized if they do something 'bad' but so far this looks to me like just a tech guy explaining (interesting) tech details.  I guess the purpose of the OTP bits is questionable in itself, but until they start refusing support based on that, maybe it would be good to see how it turns out, rather than trying to solve a problem that hasn't happened yet.  As a tech guy myself, I like to log as much information as I can, if it may help me understand how/what/why later.  Maybe it's just something that would be interesting to graph.. I may be totally off on this, but my feeling is that they would probably help you if you broke your RPi by overvolting it.. maybe not though, maybe they would burn you at the stake.  But really until that happens, this is not something to get all up in arms about.. it's quite a jump from evidence-bit to evil mega corporation.

I guess the OTP bit is seen as some kind of evidence of guilt and that's why people are upset.. because of the possibilities that raises.. what if their device has the guilty mark and they are refused support because of it?

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

Re: config.txt

Thu Feb 23, 2012 7:44 am

Nobody here is calling the foundation an evil corporation, far from it.

We just found a bug in their algorithm and suggested ways they could fix it. There were a lot of us with opinions that we felt were important, so the discussion was fairly brisk and extensive. But nobody was accusing the foundation of being evil, they just missed seeing a possible eventuality. Us software types are used to that; it happens to us every day. No blame attaches to it.

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

Re: config.txt

Thu Feb 23, 2012 8:28 am

I would also like to say that the discussion may have been heated at times, but i thought it stayed rather civil nonetheless.

User avatar
PReDiToR
Posts: 16
Joined: Thu Mar 08, 2012 5:53 pm
Contact: Website

Re: config.txt

Thu Mar 15, 2012 2:34 am

I was a little git at school here in the UK. We had ~13 Model Bs and 2 Masters.

I am now a much nicer person, which I mention for purely narcissistic reasons.

I can assure you that some child will read this discussion, and it only takes one little sod to hand round a dodgy SD for people to play "Angry Pis" on and a whole classroom full of RasPis are outside warranty. Then should someone write a program that induces a fault the whole Internet will know of it in minutes because of social networking.

Your good selves may not be able to envision the type of person that will be in contact with these devices. The milk in the printer story was for a reason, some kids don't need a reason.

nullstring, what makes you think that the program to lock/unlock would stay in the hands of the white hats? That which can be written can be copied. I mean, you could try putting DRM in it, or obfuscation, even only giving it to adults, but I can point to a few industries where those solutions haven't stopped kids.

The paperwork should have in bold as soon as possible "Essential warranty information" about using the red card to disable OCing of any description. These are for kids, not for hackers, they are teaching aids not ricers' cars. Lock those abilities down and hope the locks are strong enough for them to be safe to run any software on.

Just my £0.02.

PS Where is the preview?
Do not meddle in the affairs of geeks
for they are subtle and quick to anger

ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: config.txt

Wed Mar 28, 2012 7:07 pm

Benedict White said:


Dom, firstly well done, and thankyou very much for this.

Is it possible to turn off the GPU in part for headless mode, giving more RAM to the CPU.

I presume we will not be able to use raw GPU power for normal programs.



old post, late reply:

Sometimes it just might, eg: in instances where the pi is used as a bittorrent client, or server on batteries, serving webpages without search feats or advanced programming.
in such cases the pi would benefit from undervolting, and in case of a power failure, and it runs from batteries lasts a few hours longer.

Also in modes where only 2D info like where mainly text is being displayed instead of moving graphics, or cpu intense calculations.

ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: config.txt

Wed Mar 28, 2012 7:21 pm

dom said:


mkopack said:


Is there any plan to include options such as turning off features (like, say, if I'm going to run completely headless, turn off the components/subcircuits driving the HDMI + Composite ports to save on power? (Not even sure if that sort of thing is possible on the SoC, but if it is, it would be great if we COULD control that…)


It is possible. I've a feeling its down at the tens of milliwatts level, so it's not going to save a fortune. I'll look into it.


Is there a way to create software that auto under/over clocks?

Underclocking might be beneficial when the pi is operating at well below 50% of it's capabilities (eg: send and receive network data, has only 5% of CPU usage, or used as media player, where only 10% of the CPU is in use). At those moments, the part of the CPU working is running at 700Mhz, but it does not need to.
It would be nice if we could have a software under/overclocking agent, that could eg:
be set to:
- mobile: underclocking to 350, 175, 87 or 44Mhz (auto trigger)

- Stock: 700Mhz

- Performance: Auto overclock when needed to:

1- Safe performance (eg: 800Mhz)

2- Top performance ( variable Mhz, depending on internal temperature measurement)

- Custom: Set a fixed value, used for overriding other under/overclocking mechanisms, to clock at more extreme speeds, or set the CPU to a fixed value outside of standard overclocking (eg to avoid throttling); so one could eg: set the CPU to 750Mhz fixed and have autotune (cpu auto scaler) disabled.

I know a custom and stock setting one can do in config.txt, but I wondered if there's could be created a program that would access these values from the GUI, and that incorporates auto overclocking mechanism based on CPU/GPU usage, and temperature, and deduct the most safe and sound values from there?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5331
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: config.txt

Wed Mar 28, 2012 7:58 pm


ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: config.txt

Wed Mar 28, 2012 8:56 pm

rurwin said:


@PimpMyPi

See my post on the first page. I gave a link to a definition of all the CEA modes.



Make 2 hardware pins, that require soldering.

When short circuiting both pins the device can overvolt!
Very hard to get rid of traces that show tampering with the device.

Then again, someone could put aluminum foil over the pins and achieve the same results.

For that reason it might be better to do the opposite:
Create a small wire between 2 points. When the wire is cut, and the connection is broken, overvolting will become possible, and warranty void.

Tampering will be easily seen as a new wire will need to be soldered of exactly the same size and looks. The overvolting lock could still be enabled after resoldering the broken wire together again; should be easy,hard to find, even for kids.

And warranty can easily be found. A hardware mod is always better than a software mod.

User avatar
Davespice
Forum Moderator
Forum Moderator
Posts: 1662
Joined: Fri Oct 14, 2011 8:06 pm
Location: The Netherlands
Contact: Twitter

Re: config.txt

Thu Mar 29, 2012 10:41 am

Hi guys;

I thought I would also post about this here since it somewhat relevant.

I have written a Qt program to create this file.  I know it’s easy enough to do it through vim or whatever but this saves you having to look up what the options should be on the wiki.  More info about it here on my blog.

A couple of people have contacted me to say the program could be a Raspberry Pi self destruct button because I have included the over-volting options.  I take the point, however anyone can still set these options with a text editor despite my program.  The program builds its controls and options from a file called settings.xml which will appear in the same folder as the program.  If you edit this XML file (it should be fairly obvious what is going on) you could remove the whole over-volting group of options – or modify the options so that you could only under-volt the device.  Comments welcome.

Anyway here is a screen shot;


ProDigit
Posts: 374
Joined: Tue Aug 30, 2011 1:24 am

Re: config.txt

Thu Mar 29, 2012 6:10 pm

@Davespice: Very nice!
You think there's a possibility to mimic Intel's turbo boost, by having a program that automatically over/underclocks depending on the CPU usage? (talking about safe overclocking without modifying the voltage)

Return to “General discussion”