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 7:51 pm

Hi ProDigit,

As far as I know the config text file is only read at boot time by the GPU, so I don't think it is possible to make changes take effect without performing a reboot.  Someone please correct me if I am wrong.

Dave

Mjiig
Posts: 21
Joined: Mon Dec 05, 2011 8:44 pm

Re: config.txt

Mon Apr 02, 2012 5:42 pm

dom said:


Necessary for booting:

bootcode.bin : 2nd stage bootloader, starts with SDRAM disabled

loader.bin : 3rd stage bootloader, starts with SDRAM enabled

start.elf : The GPU firmware ("the blob")

cmdline.txt : kernel command line parameters

kernel.img : The OS kernel for the ARM

Additional kernels supplied, need to rename to kernel.img to use

kernel_emerergency.elf : kernel with busybox rootfs. Can be used for running e2fsck.

Additional blobs, need to rename to start.elf to use:

arm128_start.elf : 128M ARM, 128M GPU split

arm192_start.elf : 192M ARM, 64M GPU split

arm224_start.elf : 224M ARM, 32M GPU split

Optional:

config.txt : GPU firmware configuration options.

vlls : directory containing additional GPU code, such as extra codecs. Not used for initial release.

In theory we could make bootcode.bin load start.elf directly, so loader.bin may disappear in the future.


Let me just check I understand everything and as a question or two When I press the power button on the Pi there has to be an SD card in the slot that holds all of the required files mentioned above on a boot partition (does it require any particular filesystem or position on the card or can it just be at the root of any partition?). Bootcode.bin, loader.bin and start.elf will just be foundation produced binaries I take it, and as a programmer I just need to care about commandline.txt and kernel.img. kernel.img is just a *RELATIVELY* standard program except that as an operating system it starts in privileged mode and it accesses it's commandline parameters in much the same way that any other program does?

I assume I've missed or mistaken at least something so do let me know what

Thanks

Angus

(Also sorry for going back like 9 pages in this discussion but it seemed like the best place to ask )

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: config.txt

Mon Apr 02, 2012 6:06 pm

Hi angus.

1 - no power button.
2 - no, the kernel image is not a "fairly standard" program (nothing like one, in fact), and it has no arguments. It"s an image that is loaded at 0x00000000, and starts with an arm exception vector table.

Simon

Mjiig
Posts: 21
Joined: Mon Dec 05, 2011 8:44 pm

Re: config.txt

Mon Apr 02, 2012 6:55 pm

I did actually know about the exception vector table but completely forgot about it when posting. Regarding the arguments that was new to me. How does the kernel get at it's options then? (GRUB I think allows passing of "command line" options to linux, and on the RiPi that appears to be the point of cmdline.txt).

At the risk of digging a deeper hole, once you get past the exception vector table, is it just a machine code program executing in supervisor mode? (which I appreciate is still a simplification, but the point I'm trying to get at is that I think it's the output of a normal assembler but running under unusual conditions).

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: config.txt

Mon Apr 02, 2012 7:22 pm

Mjiig said:


Regarding the arguments that was new to me. How does the kernel get at it's options then? (GRUB I think allows passing of "command line" options to linux, and on the RiPi that appears to be the point of cmdline.txt).


I'm not actually 100% sure.  I believe that the kernel is built with a certain amount of space allocated for parameters (COMMAND_LINE_SIZE is defined in /arch/XXX/include/asm/setup.h, and a static array of characters is then created in setup.c, if I recall correctly); it is then (again, if I understand correctly, but I may well be waaaay off base), the booter's job to "inject" boot time parameters into that array before passing execution off to the kernel.  Where and how this is done is entirely architecture / machine / booter specific.


At the risk of digging a deeper hole, once you get past the exception vector table, is it just a machine code program executing in supervisor mode? (which I appreciate is still a simplification, but the point I'm trying to get at is that I think it's the output of a normal assembler but running under unusual conditions).


Initially, yes.  At the point where you've jumped out of the reset vector, you have a system which is pretty much in a running state.  You're in supervisor mode (you always are after a reset), interrupts are off, and you have no stack pointer, so you need to be really, really, bloody careful.

Simon

User avatar
Feakster
Posts: 35
Joined: Sun Jan 22, 2012 10:41 pm

Re: config.txt

Fri May 11, 2012 11:39 am

With the command:

"arm_freq=800"

... will the ARM processor be constantly running at 800MHz, or does this set a max clock rate that the chip can reach?

summers
Posts: 63
Joined: Mon Jan 30, 2012 4:27 pm

Re: config.txt

Fri May 11, 2012 11:53 am

Mjiig said:


Regarding the arguments that was new to me. How does the kernel get at it's options then? (GRUB I think allows passing of "command line" options to linux, and on the RiPi that appears to be the point of cmdline.txt).


Probably the easiest way is to compile the kernel with whatever flag you want passed. Modern kernels can be compiled this way. Of course these flag will then be fixed in that kernel image, so you won't be able to change at boot time.

Your other option is to initially load a boot loader (das u-boot would be the obvious one for arm) – and have that then load the kernel. Most bootloaders should be able to set kernel options.

Cmdline.txt just gets passed by the *blob* that gets the GPU up and working (before the arm is started). So cmdline.txt I don't think gets passed onto the kernel in anyway

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

Fri May 11, 2012 12:44 pm

@Freakster

Currently the ARM frequency is fixed, so will always be 800MHz.

@summers

cmdline.txt is written by GPU blob to space allocated for "ATAGs" inside the kernel image (at 0x100). The kernel *will* see the command line arguments.

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

Re: config.txt

Fri May 11, 2012 1:11 pm

There must have been some sort of miscommunication.  I can't understand how anyone could think that changing cmdline.txt would have no effect (on anything…)
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
grumpyoldgit
Posts: 1452
Joined: Thu Jan 05, 2012 12:20 pm

Re: config.txt

Fri May 11, 2012 1:45 pm

Can you explain to an idiot like myself this 800MHz thing. If the ARM frequency is fixed at 800MHz, what is it that the arm_freq command in config.txt is changing?

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

Fri May 11, 2012 2:06 pm

@Grumpyoldgit

I was responding to:

Feakster said:


With the command:

"arm_freq=800"

... will the ARM processor be constantly running at 800MHz, or does this set a max clock rate that the chip can reach?


So, it will be fixed at whatever frequency you specify in config.txt, otherwise the default of 700MHz. We don't currently have a variable frequency (for power saving).

User avatar
grumpyoldgit
Posts: 1452
Joined: Thu Jan 05, 2012 12:20 pm

Re: config.txt

Fri May 11, 2012 2:18 pm

Gotcha. Thanks.

summers
Posts: 63
Joined: Mon Jan 30, 2012 4:27 pm

Re: config.txt

Fri May 11, 2012 3:29 pm

dom said:

@summers
cmdline.txt is written by GPU blob to space allocated for "ATAGs" inside the kernel image (at 0x100). The kernel *will* see the command line arguments.


OOps yes - i was think of config.txt ....

UnaClocker
Posts: 12
Joined: Sat May 12, 2012 5:48 pm
Contact: Website

Re: config.txt

Sat May 12, 2012 6:54 pm

I'm having a hard time understanding the overvolting settings. Where did you get the -16,8? Why are you going from a single 1.2v to a .8v and 1.6v? Does it run .8v at idle and 1.6v under load after this change? Wouldn't I simply change the 1.2v to 1.6v? What's the command for that? -16?

User avatar
rew
Posts: 423
Joined: Fri Aug 26, 2011 3:25 pm

Re: config.txt

Sat May 12, 2012 7:18 pm

I have another browser  window op saying "life expectancy" at the top. That made me thing of "life expectancy" when you say 1.6V: I'd guess between 4 and 30 seconds.

Some things are not implemented yet. To get maximum power savings, you need to lower the CPU clock when the CPU is not maxed out. Once the clock has been lowered, you can lower the voltage. Dom has said that dynamically messing  with the CPU clock hasn't been implemented yet. So messing with the voltage is probably in the same area: not implemented.
Check out our raspberry pi addons: https://www.bitwizard.nl/shop/

LastSilmaril
Posts: 167
Joined: Wed May 09, 2012 8:16 pm
Location: New York, USA

Re: config.txt

Sun May 13, 2012 11:02 pm

My TV, which is 1360x768 native, isn't detected as such properly. I tried to force it by using hdmi_group=2 and hdmi_mode=0x27 but that just resulted in a failure to get any video on boot. hdmi_group is not mentioned on the wiki, so is it deprecated or something? would hdmi_drive=1 be the analog?

User avatar
jsidebottom
Posts: 19
Joined: Wed Mar 07, 2012 12:34 am

Re: config.txt

Tue May 15, 2012 3:43 am

UnaClocker wrote:I'm having a hard time understanding the overvolting settings. Where did you get the -16,8? Why are you going from a single 1.2v to a .8v and 1.6v? Does it run .8v at idle and 1.6v under load after this change? Wouldn't I simply change the 1.2v to 1.6v? What's the command for that? -16?
I'm not sure who you're replying to, but I'll try to answer.
You have a single parameter, that is the voltage that the area of the chip will run at from that point. The numbers are given in square brackets to show the range, not 2 parameters.
The values go from 0.8V to 1.4V, in 0.025V increments, and are given as a reference to the base voltage.
IE, default is 0 (1.2V).
If you set to -16: V = 1.2V +(-16x0.025V) = 0.8V
If you set to 8: V = 1.2V + (8x0.025V) = 1.4V
At least, that was my understanding of it.

UnaClocker
Posts: 12
Joined: Sat May 12, 2012 5:48 pm
Contact: Website

Re: config.txt

Tue May 15, 2012 4:42 am

Interesting, thanks for the tip, jsidebottom.

User avatar
SQLEinstein
Posts: 13
Joined: Thu Jul 19, 2012 4:13 pm

Re: config.txt

Tue Aug 28, 2012 2:13 pm

dom wrote:Overclocking.

It is the intention that most users stick with the default clock frequencies. That will give you the longest lifetime of the chip, and the most reliability.

If however you don't mind risking a little stability and chip lifetime, you can tinker with these, and get a little more performance.

Just overclocking (without overvoltaging) is unlikely to have a significant impact on chip lifetime. What you will find, is when you set it too high, you will see random crashes (probably kernel panics).

I would expect that there is a good chance 800MHz will be reliable, and you may be fine with 900MHz. This is assuming room temperature. At extreme temperatures (especially hot) you may have less success. Please note, this is my personal experience from a small number of chip batches - only 700MHz is guaranteed.

Now you can only go higher when you also over voltage. This is when it gets a little riskier. This does have a measurable impact on chip lifespan. Because of this, we will officially recommend you do not do this. Treat this as a voiding warranty situation. We wil blow an OTP (one-time-programmable) bit if you use the over_voltage_* settings, so we will know.

With over_voltage set to 6 (1.35V) I've been running at 1GHz for much of the last couple of months with no noticable problems. Brief tests have been successful at 1.15GHz. I may have voided my warranty however...

over_voltage applies to both the ARM and GPU. Brief tests running the GPU at 500MHz were successful for me. Even if the GPU is not providing any acceleration, you do get a small performance boost for the ARM when core_freq is higher, as the ARM has to cross the core_freq domain to get to SDRAM (or L2). This probably is more noticable when L2 is enabled.

I have not experimented too much with SDRAM overclocking. I would expect 500MHz to be achievable.
Hi Dom,

Are you still running at 1GHz with over_voltage set to 6? Would it be possible for you to post the contents of your config.txt?

Thanks!

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

Re: config.txt

Tue Aug 28, 2012 2:22 pm

Please search forum for 'overclocking' - there is a thread all about it!
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."

LemonLicker
Posts: 20
Joined: Wed Sep 26, 2012 3:51 pm

Re: config.txt

Sat Feb 16, 2013 7:14 pm

[quote="dom"][/quote]

Hey ;D

What hdmi_mode do I need for 1280x1024?

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

Sun Feb 17, 2013 12:13 pm

LemonLicker wrote:
Hey ;D

What hdmi_mode do I need for 1280x1024?
http://elinux.org/RPi_config.txt

hdmi_group=2
hdmi_mode=36

You might also want
hdmi_drive=2
if your display supports hdmi audio.

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

Re: config.txt

Sun Feb 17, 2013 12:26 pm

This is a very old thread. Some of the information in it will now be misleading. The question has been answered.

So I'm locking it.

Return to “General discussion”