1500MHz lock?

[dom]

I'd say rename it "start.elf" and put it in /boot, after renaming the original file to something else like "start.old".

Correct, although if camera is enabled (through raspi-config or by adding start_x=1 to config.txt) then you should rename it to start_x.elf.
Running

Code: Select all

vcgencmd version

Should report 6th August after doing this.

[shuckle]

vcgencmd version

reports Aug 6 after rpi-update already.

[Rsnubje]

You can just replace the start.elf while in raspbian?

[RaTTuS]

You can just replace the start.elf while in raspbian?

yes it will not be locked or anything

[dom]

vcgencmd version

reports Aug 6 after rpi-update already.

Ah. The test build should report "(tainted)". The rpi-update version should report "(clean)".

[shuckle]

Code: Select all

$ vcgencmd version
Aug  6 2014 17:51:37 
Copyright (c) 2012 Broadcom
version 3da89bd3cdef7980b684f48fe60944aff4502f50 (tainted) (release)

after rpi-update

[AndrewS]

Code: Select all

$ vcgencmd version
Aug  6 2014 17:51:37 
Copyright (c) 2012 Broadcom
version 3da89bd3cdef7980b684f48fe60944aff4502f50 (tainted) (release)

after rpi-update

Ditto

[Rsnubje]

Got that now too. Probably going for new record in the weekend If all works well that is.

[dom]

Code: Select all

$ vcgencmd version
Aug  6 2014 17:51:37 
Copyright (c) 2012 Broadcom
version 3da89bd3cdef7980b684f48fe60944aff4502f50 (tainted) (release)

after rpi-update

Bah! We sometimes get "(tainted)" on official releases, I think due to a perforce<->git mirror.
I commit changes and kick off a buid, but the mirror rewrites the newest git commits after syncing with perforce and that shows up as "(tainted)".

The test build will show:

Code: Select all

vcgencmd get_mem gpu
gpu=256M

whatever gpu_mem setting you have, whereas an official build will match the gpu_mem setting in config.txt.

[bryanandaimee]

Hmm, is the 256M GPU setting going to play havoc with my old 256M model B?

[bryanandaimee]

2014-08-10-1400MHz 1.8V.jpg (59.55 KiB) Viewed 5046 times

Well I was able to volt mod the Pi with just an LM317 for the core voltage control. I was able to get to 1400 MHz using my ghetto setup. That was at 1.8V. I can't seem to get above that stable with my current setup even at higher voltages. I am using a wall wart supply so I'll have to try a better supply for my next tests.

Knocked 8 seconds off my best time for calculating 3141593 decimal places of Pi.

Bryan

[Rsnubje]

Best I could do for now is 1550MHz. I think my usb adapter was having a faulty cable because it fell out or went on when I shake it Will try tomorrow with a new cable.

With the attached external power, 2.1V is max I can do.





[EDIT] Just realised I forgot to do a very important mod, to be exact, remove the L5 resistor, which I put back on it after last time.

[bryanandaimee]

Doesn't look like a power supply problem. I'm getting SD card corruption at higher core voltages regardless of which power supply I use. Of course it might be the LM317, but I'm goint to try setting core freq back to 250 and try a couple different SD cards next.

Bryan

[bryanandaimee]

Well I did get to 1450 MHz but I'm still fighting SD card corruption issues at higher core voltages. It helped a little to separate the 5V supply from the core supply. Not sure what problems that might cause though with 5V starting up one or two seconds before the core voltage.
I set the core clock back to 250 and the memory back to 400 so I'm assuming that's out as an issue. I used a couple different brands of SD card so I think that's out.
So I'm left with bad power supply (I've tried a few) or simply the result of increasing the core voltage too high. (I'm at 2.0V now)

I guess my next steps will be to add some bulk capacitance to smooth the supplies, and lowering the voltage just a bit. I think 2.0V is more than I need for 1450 MHz anyway so I might get further with lower volts than I did at 2.0V.

So here are my questions for the group.

Is there a good reason why increasing core voltage would directly cause SD card corruption?

Any other suggestions?

Bryan

[rpdom]

Any other suggestions?

Is USB stable at that speed?

If so, use a USB disk for your root file system, preferably with its own PSU. Disks are a lot less likely to corrupt than cards. Then you only need /boot on the SD card which rarely gets written to while running. Actually, if you set /boot to read only in fstab it'll only get written to if you remount it rw for changing settings.

[ogblaz]

Is there any good soul here to make above 1500 mod file for the 256Mb ram rpi. I tried this file here but my pi doesnt boot...
I am serious overclocker i put my pi on LN2 an used 1.8v mod on the soc so please help!!!
http://hwbot.org/submission/2912500_

Want to push on 1st place

Thanks in advance friends.

[dom]

I had a look at this. It seems there is a 3.2GHz limit on PLLs and you need at least a divide by 2 on the output to get an even duty cycle.
This means >1600MHz doesn't (trivially) work.
I've increased the limit from 1500 to 1600 with latest rpi-update, so you can give that a try.

[ogblaz]

Thanks dom that worked! I got it benchmarking on TEC at -18°C , at the soc there was about 1-3°C at 1590mhz. But there is crazy sd card corruption, now I am exploring the world of installing rasbian on usb drive, so i dont have nothing to show

Thanks again for your help, will get back when I have something to brag about

[LeandroLuquetta]

Hi everyone, I would like to know if anyone reached more than 1600mhz stable on the raspberry pi 3 or pi 3b+ (bcm2837), because I couldn't surpass the 1600mhz limit, even with external power suply for overvoltage. I think raspberry pi have any lock in the software...