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

Re: config.txt

Sun Feb 12, 2012 1:34 am

rockhawk said:


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.



There is a separate file (cmdline.txt) for kernel command line parameters.

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

Re: config.txt

Sun Feb 12, 2012 1:43 am

zippy said:


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.


From linux there is a standard /dev/fb0 driver. You can use that to poke pixels onto the screen (and change size/format of framebuffer).

For non-linux you set up a structure describing the framebuffer and poke its address through a mailbox register (see 2708fb.c in linux driver).

The actual video display hardware is connected to the GPU, so the ARM cannot set up the low level control (as in pixel clocks, syncs, front and back porches etc.)

plugwash
Forum Moderator
Forum Moderator
Posts: 3439
Joined: Wed Dec 28, 2011 11:45 pm

Re: config.txt

Sun Feb 12, 2012 2:09 am

Going through the list I was surprised not to see an option for the CPU/GPU memory split mentioned in the "arm perhipherals" datasheet. How will this be controlled (or will it just be fixed at some value and unchangable for mere mortals?)

zippy
Posts: 21
Joined: Fri Dec 30, 2011 1:28 am

Re: config.txt

Sun Feb 12, 2012 2:43 am

Interesting, thanks.

I'd be aiming to do this direct in ARM code without any OS (or maybe in RISCOS via the BASIC assembler if the appropriate SWI calls are implemented, I guess we'll find that out when the RasPi RISCOS appears) as I don't know anything about C or Linux. I have a couple of old ARM graphic demos I wrote on the A3000 I'd like to get running for a start, just to see what's possible.

I'll take a look at 2708fb.c though as I may be able to pull the necessary hardware addresses out of it, thanks for the tip.

Any info. on the framebuffer description structure would be great. I take it the framebuffer will have an alpha channel implemented in hardware so we won't have to do masking in software as was required on the Archimedes hardware?

Basically if we can access a dumb 2D framebuffer direct from ARM in the same way as was possible on the A3000 that would be great. All that would be needed beyond that would be basic stuff like how to detect vsync and how to switch active screen buffers for double buffering etc., just basic stuff.

Apologies for going offtopic btw.

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

Re: config.txt

Sun Feb 12, 2012 4:06 am

Very nice, I definatly will be pushing one to the limits just to see how far it goes before failure.  That is after we can get more than one per house.  I don't wan't to cook one and be SOL in regaurds to all my projects.

Very good news to hear you have one running at 1Ghz.  Gives me hope that we will see some good emulation results.

Sorry if I missed this in the context somewhere (I went back and re-skimmed.)  Can we overclock the VideoCore?  Or does it OC with the host ARM core?

EricMiddleton
Posts: 47
Joined: Wed Jan 18, 2012 3:47 am

Re: config.txt

Sun Feb 12, 2012 5:36 am

Is it possible to change the clock and/or voltage settings while in linux? It seems very useful to be able to boost the clock when processing a lot and then lower it when idle to save battery power.

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

Re: config.txt

Sun Feb 12, 2012 7:16 am

Is the above list of resolutions the only set supported by the GPU, or will it negotiate to native resolution of any DVI monitor if left alone?  I have one with 1920x1200 and the office has lots of examples midway between 720p and 1080p.

Does the OTP bit get blown even if the chip is *under* volted?  People interested in reducing power consumption are likely to try that rather than increasing it.
The key to knowledge is not to rely on people to teach you it.

ElectronikHeart
Posts: 20
Joined: Tue Feb 07, 2012 4:08 pm

Re: config.txt

Sun Feb 12, 2012 9:14 am

Is it possible to totally allocate the L2 cache to the CPU ? Does this have an impact even on non hardware accelerated display ?

Is enabling the L2 cache for the CPU means that I have to run a MMU disabled Linux kernel ? (which is not what I want for a server for example)

Thank you very much for this config.txt file. It's a very great and well done tool for tweaking a raspberry. I think I will try to stick a heatsink on my RasPi and overclock/overvolt it ^^ The PoP memory is a problem for heat dissipation I think.

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

Re: config.txt

Sun Feb 12, 2012 10:25 am

plugwash said:


Going through the list I was surprised not to see an option for the CPU/GPU memory split mentioned in the "arm perhipherals" datasheet. How will this be controlled (or will it just be fixed at some value and unchangable for mere mortals?)



You are quite right that would be the obvious place to specify the memory split. Unfortunately it's tricky to do that The ARM memory split starts at zero and the GPU split sits above the ARM split. By the time the config.txt file it read, the GPU has already been loaded at the "split" address so it's too late to change. The GPU code addresses were actually fixed at link time.

We will supply 3 versions of the GPU firmware built for different split sizes (ARM with 128M, 192M and 224M). We hope to eventualy use CMA to handle dynamically moving the memory split, but that's a significant job that will take a while.

rockhawk
Posts: 54
Joined: Thu Feb 09, 2012 9:24 pm
Contact: Website

Re: config.txt

Sun Feb 12, 2012 10:28 am

dom said:


There is a separate file (cmdline.txt) for kernel command line parameters.


Excellent!  So the boot partition contains:


kernel.img: The OS kernel for the ARM
?filename?: The GPU firmware ("the blob")
config.txt: Parameters read by the GPU to control system setup
cmdline.txt: Kernel parameters

Is there anything else there?  Time to get this stuff on the wiki, methinks.
Find Iridium Rising, our 3D space combat game, on the Pi Store!

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

Re: config.txt

Sun Feb 12, 2012 10:28 am

Jessie said:


Sorry if I missed this in the context somewhere (I went back and re-skimmed.)  Can we overclock the VideoCore?  Or does it OC with the host ARM core?



You should skim once more!

gpu_freq overclocks the whole of VC. core_freq overclocks just the VC core processor. ARM and GPU share the overvoltage setting.

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

Re: config.txt

Sun Feb 12, 2012 10:35 am

Eric Middleton said:


Is it possible to change the clock and/or voltage settings while in linux? It seems very useful to be able to boost the clock when processing a lot and then lower it when idle to save battery power.



Not currently, but the intention is to move some of these settings into ARM kernel drivers eventually. Suggestions for which kernel drivers the settings belong in, or even better kernel patches will encourage me. Go as far as printing out what needs to be done, and I'll add in the plumbing to GPU (probably a mailbox message).

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

Re: config.txt

Sun Feb 12, 2012 10:43 am

Chromatix said:


Is the above list of resolutions the only set supported by the GPU, or will it negotiate to native resolution of any DVI monitor if left alone?  I have one with 1920x1200 and the office has lots of examples midway between 720p and 1080p.

Does the OTP bit get blown even if the chip is *under* volted?  People interested in reducing power consumption are likely to try that rather than increasing it.


I believe that is the complete list of CEA resolutions (i.e. TV HDMI modes). There is a different list of DMT resolutions (i.e. PC DVI modes) supported which has settings like 1440x900. I will dig out that list (I think it is specified in the standards).

Undervoltage should not blow the OTP bit. I believe it will not harm the chip (but will causes crashes if you go too low).

Here is the list. 1920x1200 is there (and that is the highest supported resolution - that is pretty much the limit of the pixel clock).

HDMI_DMT_640x350_85 = 0x1, /**<640x350 */
HDMI_DMT_640x400_85 = 0x2, /**<640x400 */
HDMI_DMT_IBM_VGA_85 = 0x3, /**<720x400 */
HDMI_DMT_VGA_60 = 0x4, /**<640x480 (60Hz is same as VGA above) */
HDMI_DMT_VGA_72 = 0x5,
HDMI_DMT_VGA_75 = 0x6,
HDMI_DMT_VGA_85 = 0x7,
HDMI_DMT_SVGA_56 = 0x8, /**<800x600 */
HDMI_DMT_SVGA_60 = 0x9,
HDMI_DMT_SVGA_72 = 0xA,
HDMI_DMT_SVGA_75 = 0xB,
HDMI_DMT_SVGA_85 = 0xC,
HDMI_DMT_SVGA_120 = 0xD,
HDMI_DMT_848x480_60 = 0xE, /**<848x480 */
HDMI_DMT_XGA_60 = 0x10, /**<1024x768 */
HDMI_DMT_XGA_70 = 0x11,
HDMI_DMT_XGA_75 = 0x12,
HDMI_DMT_XGA_85 = 0x13,
HDMI_DMT_XGA_120 = 0x14,
HDMI_DMT_XGAP_75 = 0x15, /**<1152x864 */
HDMI_DMT_WXGA_RB = 0x16, /**<1280x768 reduced blanking */
HDMI_DMT_WXGA_60 = 0x17,
HDMI_DMT_WXGA_75 = 0x18,
HDMI_DMT_WXGA_85 = 0x19,
HDMI_DMT_WXGA_120 = 0x1A, /**<120Hz with reduced blanking */
HDMI_DMT_1280x800_RB = 0x1B, /**<1280x800 reduced blanking */
HDMI_DMT_1280x800_60 = 0x1C,
HDMI_DMT_1280x960_60 = 0x20, /**<1280x960 */
HDMI_DMT_1280x960_85 = 0x21,
HDMI_DMT_SXGA_60 = 0x23, /**<1280x1024 */
HDMI_DMT_SXGA_75 = 0x24,
HDMI_DMT_SXGA_85 = 0x25,
HDMI_DMT_1360x768_60 = 0x27, /**<1360x768 */
HDMI_DMT_1360x768_120 = 0x28, /**<120 Hz with reduced blanking */
HDMI_DMT_SXGAP_RB = 0x29, /**<1400x1050 reduced blanking */
HDMI_DMT_SXGAP_60 = 0x2A,
HDMI_DMT_SXGAP_75 = 0x2B,
HDMI_DMT_1440x900_RB = 0x2E, /**<1440x900 reduced blanking */
HDMI_DMT_1440x900_60 = 0x2F,
HDMI_DMT_1440x900_75 = 0x30,
HDMI_DMT_1440x900_85 = 0x31,
HDMI_DMT_UXGA_60 = 0x33, /**<1600x1200 60Hz */
HDMI_DMT_SWXGAP_RB = 0x39, /**<1680x1050 reduced blanking */
HDMI_DMT_SWXGAP_60 = 0x3A, /**<1680x1050 60Hz */
HDMI_DMT_WUXGA_RB = 0x44, /**<1920x1200 reduced blanking */
HDMI_DMT_1366x768_60 = 0x51, /**<1366x768 60Hz */
HDMI_DMT_1080p_60 = 0x52, /**<Same as 1080p60 above */
HDMI_DMT_1600x900_RB = 0x53, /**<1600x900 reduced blanking */
HDMI_DMT_720p_60 = 0x55, /**<Same as 720p60 above */
HDMI_DMT_1366x768_RB = 0x56, /**<1366x768 reduced blanking */

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

Re: config.txt

Sun Feb 12, 2012 11:07 am

ElectronikHeart said:


Is it possible to totally allocate the L2 cache to the CPU ? Does this have an impact even on non hardware accelerated display ?

Is enabling the L2 cache for the CPU means that I have to run a MMU disabled Linux kernel ? (which is not what I want for a server for example)



It is technically possible to stop the GPU from using the L2 cache. It is not trivial, and would require a separate build of firmware (it is too late by time config.txt is read). I will think about it. The GPU does certain housekeeping task even when not being used for acceleration. Disabling L2 will make those less efficient, and will increase the traffic to SDRAM which could impact ARM. However the GPU is typically 99% idle in this case, so the impact should be minor.

No. ARM will always use MMU when running linux. Enabling L2 does not affect MMU.

ElectronikHeart
Posts: 20
Joined: Tue Feb 07, 2012 4:08 pm

Re: config.txt

Sun Feb 12, 2012 11:28 am

Great ! Is this possible to make a build with L2 cache for the Arm core and the less possible ram for the GPU to make a firmware for CPU intensive task with no intent to use the GPU capabilities. (I want to use the rasp as a little headless server, I think I will not be the only one wanting a firmware optimized for theses tasks).

I don't understand the thing you have said about the need a properly configured kernel to use the L2 cache(in the first post "Needs corresponding L2 enabled kernel"). If it's not for disabling MMU, what is needed from the kernel to be able to use the L2 cache ?

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

Re: config.txt

Sun Feb 12, 2012 11:42 am

rockhawk said:

Excellent!  So the boot partition contains:

kernel.img: The OS kernel for the ARM
?filename?: The GPU firmware ("the blob")
config.txt: Parameters read by the GPU to control system setup
cmdline.txt: Kernel parameters

Is there anything else there?  Time to get this stuff on the wiki, methinks.

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.

rockhawk
Posts: 54
Joined: Thu Feb 09, 2012 9:24 pm
Contact: Website

Re: config.txt

Sun Feb 12, 2012 12:08 pm

Thanks Dom this is great info!  I'm adding it to the wiki.

Could you just clarify:

- which is the default memory split (I think 192M from searching previous posts)?

- I assume you typo'd the recovery kernel filename and it should be kernel_emergency.elf  If this isn't yet set in stone - would kernel_emergency.img make more sense?
Find Iridium Rising, our 3D space combat game, on the Pi Store!

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

Re: config.txt

Sun Feb 12, 2012 12:16 pm

Yes, typo. kernel_emergency.img is the actual name.

192M is the default split. It should be sufficent for standalone 1080p video decode, or simple 3D (but probably not both together).

224M is for linux only, with just a 1080p framebuffer. Likely to fail for any video or 3D.

128M is for heavy 3D, possibly also with video decode (e.g. XBMC).

dh04000
Posts: 62
Joined: Tue Oct 04, 2011 9:18 pm

Re: config.txt

Sun Feb 12, 2012 1:55 pm

So, I'm no linux or hardware expert, but it appears to me, that I could use this config file to decrease the gpu frequency to near zero to save power if I want to use the R-P for non-video purposes. It also appears that I could give the gpu almost no ram, so I can use the extra ram for the cpu processes.

Is there anything I'm missing about this?

I want to use the R-Pi to host web-accessible NAS (just word documents mostly), personal Web-Resume, and almost anything else I can think of. Saving power and keeping the R-Pi cool are really important to me.

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

Re: config.txt

Sun Feb 12, 2012 2:10 pm

dh04000 said:


So, I'm no linux or hardware expert, but it appears to me, that I could use this config file to decrease the gpu frequency to near zero to save power if I want to use the R-P for non-video purposes. It also appears that I could give the gpu almost no ram, so I can use the extra ram for the cpu processes.

Is there anything I'm missing about this?

I want to use the R-Pi to host web-accessible NAS (just word documents mostly), personal Web-Resume, and almost anything else I can think of. Saving power and keeping the R-Pi cool are really important to me.


Using the 224M ARM split is the correct one for your usage.

You can tinker, but I'd advise against lowering the GPU frequency. Some of the ARM's memory system runs off that clock, so it will slow down the ARM.

The GPU has automatic power saving that will be disabled if you change its clock from the default. It will run cool enough without changing the default settings.

ElectronikHeart
Posts: 20
Joined: Tue Feb 07, 2012 4:08 pm

Re: config.txt

Sun Feb 12, 2012 2:11 pm

You will save nothing by decreasing the GPU frequency in term of power usage(because it set itself in power saving mode when you don't need it). But you will hurt your performance because the CPU need access to the GPU to have access to the RAM or something like that if I recall correctly.

dom as said that increasing the GPU frequency could improve CPU performance.

EDIT: my message is so redundant ^^

dh04000
Posts: 62
Joined: Tue Oct 04, 2011 9:18 pm

Re: config.txt

Sun Feb 12, 2012 3:12 pm

dom said:

Using the 224M ARM split is the correct one for your usage.
You can tinker, but I'd advise against lowering the GPU frequency. Some of the ARM's memory system runs off that clock, so it will slow down the ARM.

The GPU has automatic power saving that will be disabled if you change its clock from the default. It will run cool enough without changing the default settings.



Thank you for the advice. 

That's what I'll do.

User avatar
Burngate
Posts: 5967
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK Tralfamadore
Contact: Website

Re: config.txt

Sun Feb 12, 2012 4:36 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

In theory we could make bootcode.bin load start.elf directly, so loader.bin may disappear in the future.
Sorry, but I'm confused - if bootcode.bin starts with SDRAM disabled, how is it loaded?

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

Re: config.txt

Sun Feb 12, 2012 4:51 pm

Burngate said:


Sorry, but I'm confused – if bootcode.bin starts with SDRAM disabled, how is it loaded?


Runs from L2 cache (and is very careful)…

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

Re: config.txt

Sun Feb 12, 2012 4:59 pm

Indeed, the first stages of a PC BIOS run the same way, with the main DRAM unavailable.  One of the first tasks is to switch on and configure that, which on a PC means reading the EEPROM on each module (usually a tiny 8-pin chip in one corner) which describes what it is capable of.

Standard bootloader stuff on anything other than a PC.
The key to knowledge is not to rely on people to teach you it.

Return to “General discussion”