config.txt

[dom]

This information is probably suitable for the wiki.

We have implemented a number of configuration options in a file "config.txt" on boot partition (so /boot/config.txt from linux). These are read and acted on by GPU before the ARM boots. Some of these may become redundant in the future if we can control the options from kernel drivers.

The file is optional, and most users won't even need to create it. For a few hackers there may be some useful settings in here.

The format is "property=value". value is an integer. One option per line. # is comment character. E.g.

cat /boot/config.txt

arm_freq=800

#hdmi_mode=19

sdtv_mode=2

overscan_left=32

overscan_right=32

overscan_top=32

overscan_bottom=32

Description:

arm_freq : frequency of ARM in MHz. Default 700.

gpu_freq : Sets core_freq, h264_freq, isp_freq, v3d_freq together.

core_freq : frequency of GPU processor core in MHz. Default 250.

h264_freq: frequency of hardware video block in MHz. Default 250.

isp_freq: frequency of image sensor pipeline block in MHz. Default 250.

v3d_freq: frequency of 3D block in MHz. Default 250.

sdram_freq: frequency of SDRAM in MHz. Default 400.

over_voltage: ARM/GPU core voltage adjust. [-16,8] equates to [0.8V,1.4V]. Default 0 (1.2V)

over_voltage_sdram: Sets over_voltage_sdram_c, over_voltage_sdram_i, over_voltage_sdram_p together

over_voltage_sdram_c: SDRAM controller voltage adjust. [-16,8] equates to [0.8V,1.4V]. Default 0 (1.2V)

over_voltage_sdram_i: SDRAM I/O voltage adjust. [-16,8] equates to [0.8V,1.4V]. Default 0 (1.2V)

over_voltage_sdram_p: SDRAM phy voltage adjust. [-16,8] equates to [0.8V,1.4V]. Default 0 (1.2V)

sdtv_mode: composite tv mode. Default is 0 (NTSC)

sdtv_aspect: composite aspect ratio. Default is 1 (4:3)

hdmi_mode: hdmi mode. Default is negotiated with display.

overscan_left: number of pixels to skip on left

overscan_right: number of pixels to skip on right

overscan_top: number of pixels to skip on top

overscan_bottom: number of pixels to skip on bottom

framebuffer_width: console framebuffer width in pixels. Default matches display.

framebuffer_height: console framebuffer height in pixels. Default matches display.

test_mode: enable test sound/image during boot for manufacturing test.

enable_l2cache: enable arm access to GPU's L2 cache. Needs corresponding L2 enabled kernel. Default 0.

sdtv_mode is

SDTV_MODE_NTSC       = 0, /**<Normal NTSC */

SDTV_MODE_NTSC_J     = 1, /**<Japanese version of NTSC - no pedestal.*/

SDTV_MODE_PAL        = 2, /**<Normal PAL */

SDTV_MODE_PAL_M      = 3, /**<Brazilian version of PAL - 525/60 rather than 625/50, different subcarrier */

sdtv_aspect is

SDTV_ASPECT_4_3      = 1, /**<4:3 */

SDTV_ASPECT_14_9     = 2, /**<14:9 */

SDTV_ASPECT_16_9     = 3  /**<16:9 */

hdmi_mode is

HDMI_CEA_VGA             =  1,

HDMI_CEA_480p60          =  2,

HDMI_CEA_480p60H         =  3,

HDMI_CEA_720p60          =  4,

HDMI_CEA_1080i60         =  5,

HDMI_CEA_480i60          =  6,

HDMI_CEA_480i60H         =  7,

HDMI_CEA_240p60          =  8,

HDMI_CEA_240p60H         =  9,

HDMI_CEA_480i60_4x       = 10,

HDMI_CEA_480i60_4xH      = 11,

HDMI_CEA_240p60_4x       = 12,

HDMI_CEA_240p60_4xH      = 13,

HDMI_CEA_480p60_2x       = 14,

HDMI_CEA_480p60_2xH      = 15,

HDMI_CEA_1080p60         = 16,

HDMI_CEA_576p50          = 17,

HDMI_CEA_576p50H         = 18,

HDMI_CEA_720p50          = 19,

HDMI_CEA_1080i50         = 20,

HDMI_CEA_576i50          = 21,

HDMI_CEA_576i50H         = 22,

HDMI_CEA_288p50          = 23,

HDMI_CEA_288p50H         = 24,

HDMI_CEA_576i50_4x       = 25,

HDMI_CEA_576i50_4xH      = 26,

HDMI_CEA_288p50_4x       = 27,

HDMI_CEA_288p50_4xH      = 28,

HDMI_CEA_576p50_2x       = 29,

HDMI_CEA_576p50_2xH      = 30,

HDMI_CEA_1080p50         = 31,

HDMI_CEA_1080p24         = 32,

HDMI_CEA_1080p25         = 33,

HDMI_CEA_1080p30         = 34,

HDMI_CEA_480p60_4x       = 35,

HDMI_CEA_480p60_4xH      = 36,

HDMI_CEA_576p50_4x       = 37,

HDMI_CEA_576p50_4xH      = 38,

HDMI_CEA_1080i50_rb      = 39,

HDMI_CEA_1080i100        = 40,

HDMI_CEA_720p100         = 41,

HDMI_CEA_576p100         = 42,

HDMI_CEA_576p100H        = 43,

HDMI_CEA_576i100         = 44,

HDMI_CEA_576i100H        = 45,

HDMI_CEA_1080i120        = 46,

HDMI_CEA_720p120         = 47,

HDMI_CEA_480p120         = 48,

HDMI_CEA_480p120H        = 49,

HDMI_CEA_480i120         = 50,

HDMI_CEA_480i120H        = 51,

HDMI_CEA_576p200         = 52,

HDMI_CEA_576p200H        = 53,

HDMI_CEA_576i200         = 54,

HDMI_CEA_576i200H        = 55,

HDMI_CEA_480p240         = 56,

HDMI_CEA_480p240H        = 57,

HDMI_CEA_480i240         = 58,

HDMI_CEA_480i240H        = 59,

[dom]

(reserved: overclock info)

[dom]

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.

[drgeoff]

Nice.

[ukscone]

what about underclocking? how low can we go? doubt anyone other than me will want to other than to try it once

[drgeoff]

dom said:


We wil blow an OTP (one-time-programmable) bit if you use the over_voltage_* settings, so we will know.


But if the part isn't working any more how will you read that OTP bit to know?

[dom]

L2 cache.

The GPU has a 128K 4 way set associative cache.

The default configuration is to dedicate it to the GPU, and the ARM bypasses it.

There's a number of reasons for this. Obviously sharing the cache will mean both the ARM and GPU get less benefit due to evictions and additional cache misses.

The L2 cache is designed for the GPU. It is closer the GPU (in clock cycles), so a cache hit provides more benefit for the GPU than the ARM.

The L2 cache is outside the ARM's MMU. That means a contiguous (virtual) buffer that is significantly less than 128K may not be able to be fully cached (worst case a single 20K buffer may end up in 5 conflicting 4K pages).

I've measured latency from ARM to:

L1 cache hit 7ns.

SDRAM as 128ns (for a SDRAM page hit).

SDRAM as 167ns (for a SDRAM page miss).

L2 cache hit 68ns.

L2 cache miss 153ns (for a SDRAM page hit)

L2 cache miss 192ns (for a SDRAM page miss)

(this is actually with ARM at 600MHz. Overclocking options obviously will reduce these numbers. My latency measurment is a sequence of ld r0,(r0) instructions, which may include some processor pipeline stalls).

So with L2 cache enabled from ARM a cache hit is about twice as fast. A cache miss is significantly slower than an access with L2 disabled. Some use cases will be faster with L2 enabled, but not all. Obviously if the GPU is working hard through the cache, the ARM will be seeing more misses.

So, that's why L2 cache is disabled from ARM. However it is still worth investigating whether it speeds up some use cases (e.g. X GUI with browser).

[Bakul Shah]

Excellent addition!

In theory this can be further extended (by you guys) to specify the "kernel" to load, the amount of memory to give to the GPU etc. right? Basically parameters that would be too late to change by a loaded program [In case you are looking for suggestions ]

[Burngate]

Quote

sdtv_mode: composite tv mode. Default is 0 (NTSC)

sdtv_aspect: composite aspect ratio. Default is 1 (4:3)

hdmi_mode: hdmi mode. Default is negotiated with display.

overscan_left: number of pixels to skip on left

overscan_right: number of pixels to skip on right

overscan_top: number of pixels to skip on top

overscan_bottom: number of pixels to skip on bottom

framebuffer_width: console framebuffer width in pixels. Default matches display.

framebuffer_height: console framebuffer height in pixels. Default matches display.

Brilliant!

Thanx, Dom

[Bakul Shah]

dom said:


So, that's why L2 cache is disabled from ARM. However it is still worth investigating whether it speeds up some use cases (e.g. X GUI with browser).


In general for cases where GPU isn't (or can't be) used much such as alternate OSes or when there is no display, or just a TV attached through the composite video connection. It would be useful to compare some benchmarks with/without cache use (something we can do once we get the Raspi, provided cache sharing can be changed later).

Forgot to add in my previous comment: if the GPU code that groks config.txt *ignores* parameters it doesn't understand, the kernel/loaded program can use it to store their boot time parameters. You must have already thought of all these possibilities but just in case...!

Thanks!

[rurwin]

The CEA video resolution codes are defined here (scroll down to the bottom grey block). There may be differences though. The source document, CEA/EIA-861D is not easy to find and even less easy to understand.

@dom, thanks for this, a great teaser.

What are the pixel resolutions for sdtv?

...and who made the mistake in HDMI modes 58&59? (I'm blaming Wikipedia for now )

[liz]

I should point out that there's a one-time programmable bit on the device which will set if you've overvolted your device. If that sticky bit is set, it tells us that the Raspberry Pi has been overvolted, so any warranty won't apply if you try to send it back to us and say "it's broken". You can overclock without overvolting, but this won't get you as much headroom as overvolting would.

[Burngate]

liz said:


I should point out that there's a one-time programmable bit on the device which will set if you've overvolted your device. If that sticky bit is set, it tells us that the Raspberry Pi has been overvolted, so any warranty won't apply if you try to send it back to us and say "it's broken". You can overclock without overvolting, but this won't get you as much headroom as overvolting would.



Does it have a coke-detection sticky bit as well? And will it detect dunking in cider?

[liz]

Burngate said:


Does it have a coke-detection sticky bit as well? And will it detect dunking in cider?


No; this is just another one of the many ways in which the Raspberry Pi does not resemble an Apple product.

[dom]

drgeoff said:

But if the part isn't working any more how will you read that OTP bit to know?
We can read it over jtag even if the chip doesn't boot.

[mkopack]

Awesome, so this is basically our "bios" screen where we can tweak things a bit...

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...)

Just curious. Either way, great news!

[drgeoff]

dom said:


drgeoff said:


But if the part isn't working any more how will you read that OTP bit to know?


We can read it over jtag even if the chip doesn't boot.


As Captain Mainwaring would have said: "Just testing you".

[dom]

rurwin said:

What are the pixel resolutions for sdtv?
720x480 for NTSC, 720x576 for PAL.

(But you will probably not see all the pixels due to overscan).

[dom]

ukscone said:


what about underclocking? how low can we go? doubt anyone other than me will want to other than to try it once


Yes, underclocking should be fine. I'm not sure if there is a minimum. You will lose the display when GPU goes too low (somewhere around 30MHz I think).

You may be able to undervolt as well when you do this.

It may not save you any significant power. We've generally found that allowing the GPU to run fast when busy *saves* power.

For example, playing a lowish bitrate 1080p video might require 80MHz. It's cheaper to run at 250MHz and power off most of the GPU for 2/3 of the time, than to run at 80MHz all the time.

Note, the default power management will vary the GPU core clock depending on how busy it is. So when relatively idle, it may be well below 80MHz. Once you request a specific frequency, that power management will be disabled.

(Parts of the GPU that are not being used will still be powered down whether power managament is enabled or disabled).

[dom]

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.

[Benedict White]

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.

[zippy]

Great info, thanks, good to see some detail on setting up custom video modes starting to appear.

Still hoping to see some kind of simple data sheet on setting up and manipulating a dumb 2D frame buffer as there was no mention of that at all in the initial data sheet. It's early days of course and I'm sure more details will be forthcoming as and when possible, this is all part of the fun of anticipating not only the hardware release but all the further developments that will follow.

[jamesh]

Dumb frame buffer isn't a standard use case for the device, so isn't in the datasheet. We will need to document that separately.

I'd like to look in to that actually, but not at work for next few days. I'll see if I can gather the information together and knock up something. Unless someone beats me to it.

[victhor393]

Is it possible to force resolutions on HDMI other than the "standard" TV resolutions (480p, 720p, 1080p, etc)?

[rockhawk]

Having access to this stuff is brilliant!  Thanks Dom!

As Bakul mentioned, it would be great to be able to set kernel parameters from the config file.  Would that be easy to do?  I would think a separate boot_params line would be best instead of just passing unrecognized parameters through to avoid clashing names causing problems.