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

Re: config.txt

Sun Feb 12, 2012 5:49 pm

I have to say, this is all REALLY good info, and certainly should get put in the FAQ / Wiki!

Glad to see that we're starting to get this sort of info. I figured it was just a matter of time, waiting until the boards were ready.

Here's to hoping this trickle quickly turns into a flood once the boards start getting into people's hands!

Bakul Shah
Posts: 320
Joined: Sun Sep 25, 2011 1:25 am

Re: config.txt

Sun Feb 12, 2012 6:24 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.

Which one reads config.txt? Just curious.

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

Re: config.txt

Sun Feb 12, 2012 7:19 pm

Bakul said:

Which one reads config.txt? Just curious.
start.elf

timgiles
Posts: 101
Joined: Thu Jan 12, 2012 8:58 am

Re: config.txt

Sun Feb 12, 2012 8:04 pm

Just wanted to say:

A) Cant believe I have missed this post!

B) THank you Dom and all who are involved tracking down the features and making it easy peasy for us not to guru like Linux users

Regards from north Sweden

Tim

PS. Easy one - can do it on my toes  2 + 1 = 3

pepedog
Posts: 1043
Joined: Fri Oct 07, 2011 9:55 am

Re: config.txt

Sun Feb 12, 2012 9:24 pm

Good info.

I know these are more kernel params, but they are in cmdline.txt too, are they going to be in the wiki?

console=ttyAMA0,115200
kgdboc=ttyAMA0,115200
console=tty1
loglevel=2

smsc95xx.macaddr=08:00:28:00:60:01 (Is this still needed or has serial number in GPU to mac address been addressed yet?)
root=/dev/mmcblk0p2
rootfstype=ext3 (I couldn't get ext4 to boot, either bad luck or no skill)
rootwait

init= (does this work? handy for /bin/bash)

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 11:38 pm

dom said:


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.



Sorry dom I got excited when I saw this post and didn't do my due dilligence.  I see it now.  Overclocking for the GPU looks quite robust with each block being able to have seporate clocks.  I'm very interested in doing some overclocking and geting some benchmarks done to see what impacts performance the most and for what applications.  Until hardware acceleration is avalible in most software though I'm sure the CPU core will do the most, may be the ram in some other cases.

Benedict White
Posts: 224
Joined: Sat Dec 24, 2011 12:24 am

Re: config.txt

Mon Feb 13, 2012 12:03 am

Dom, is an accelerated X driver likely?

User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5201
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: config.txt

Mon Feb 13, 2012 12:07 am

We're not currently working on one. It's certainly not beyond the capability of the community, though - and we'll let you know if we do start such a project ourselves. (You're likely to get one sooner if you do it yourselves, though.)
Director of Communications, Raspberry Pi

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

Re: config.txt

Mon Feb 13, 2012 12:17 am

Benedict White said:


Dom, is an accelerated X driver likely?


Not for initial release. I think that is something we would seek community help with. (We have little knowledge of how X works).

There are a number of possible routes, and I'm not sure which would fit best:

DMA (it can do fast 2D fills and blits)

openVG

openGL ES

dispmanx (display api that can scale/format convert/alpha blend/composite a number of rectangles onto screen)

Benedict White
Posts: 224
Joined: Sat Dec 24, 2011 12:24 am

Re: config.txt

Mon Feb 13, 2012 12:57 am

dom said:


Benedict White said:


Dom, is an accelerated X driver likely?


Not for initial release. I think that is something we would seek community help with. (We have little knowledge of how X works).


Fair enough... neither have I.  That said there is going to have to be a lot of information for the community to work on in order for them to have a clue how to write a driver.



There are a number of possible routes, and I'm not sure which would fit best:

DMA (it can do fast 2D fills and blits)

openVG

openGL ES

dispmanx (display api that can scale/format convert/alpha blend/composite a number of rectangles onto screen)


I certainly think the GPU can handle it and maybe an X developer can give a clue as to which is best. I am used to seeing X drivers that do OpenGL.

Photon Peddler
Posts: 7
Joined: Sat Nov 26, 2011 7:44 am

Re: config.txt

Mon Feb 13, 2012 2:32 am

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


Interesting. Is the built-in 1st stage bootloader capable of figuring out where bootcode.bin is in the filesystem, or does it require the file contents to be placed on certain sectors (and reserving those sectors for bootcode.bin in FAT, so they are not overwritten)? The latter case would require some extra care when preparing the SD card filesystem.

If any of the 1st .. 3rd stage bootloaders are capable of reading files out of FAT, one of them could read config.txt before start.elf, in theory.

bit-d
Posts: 1
Joined: Tue Jan 10, 2012 3:16 pm

Re: config.txt

Mon Feb 13, 2012 3:26 am

Where set up how much of RAM will be used as Video RAM ?

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

Re: config.txt

Mon Feb 13, 2012 7:29 am

Back on page 3, dom said:


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.


foo
Posts: 52
Joined: Thu Dec 29, 2011 12:49 am

Re: config.txt

Mon Feb 13, 2012 9:17 am

One of the first things I'll do is hook it to a 3840x2400 display via HDMI->DVI adapter.  Ubuntu drove it out-of-the-box at full-resolution from a single-link DVI at 12Hz refresh rate.

Any bets on if it'll actually work for the RPi?

User avatar
walney
Posts: 233
Joined: Wed Nov 30, 2011 6:57 pm
Contact: Website

Re: config.txt

Mon Feb 13, 2012 9:49 am

bit-d said:


Where set up how much of RAM will be used as Video RAM ?



If you look at post 42 in this thread, Dom says:

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

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

Re: config.txt

Mon Feb 13, 2012 9:58 am

Photon Peddler said:

Interesting. Is the built-in 1st stage bootloader capable of figuring out where bootcode.bin is in the filesystem, or does it require the file contents to be placed on certain sectors (and reserving those sectors for bootcode.binin FAT, so they are not overwritten)? The latter case would require some extra care when preparing the SD card filesystem.
If any of the 1st .. 3rd stage bootloaders are capable of reading files out of FAT, one of them could read config.txt before start.elf, in theory.


The first, second and third stage bootloaders can all read a FAT formatted partition of a sdcard. There shouldn't be restictions on where the files are on the partition.

However the first stage bootloader is in (a very small amount of) ROM. If we come across sdcards with peculiarities that mean bootcode.bin cannot be loaded there's not much we can do (except add support for future chips).

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

Re: config.txt

Mon Feb 13, 2012 10:12 am

foo said:


One of the first things I'll do is hook it to a 3840x2400 display via HDMI->DVI adapter.  Ubuntu drove it out-of-the-box at full-resolution from a single-link DVI at 12Hz refresh rate.

Any bets on if it'll actually work for the RPi?


Well, I'll bet R-Pi finds a resolution, but it won't be that one. Currently 1920x1200 is the highest resolution supported.

Now, I've asked the question, can the hardware drive higher resolutions at lower refresh rates, and the reply was "yes, in theory". This is just referring to physically driving HDMI. The problem is that there are many other places in the system that this will effect. The memory usage is the obvious one. The ARM will also be producing a much larger image when using X or the browser, so will be that much more sluggish.

I'm not sure we've got a display with that high a resolution in the office, so it may be tricky to test.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: config.txt

Mon Feb 13, 2012 10:26 am

Dom, this sounds great stuff.

Is there any chance of specifying any of these options at boot-time via the keyboard or even over serial? I could see the SD card slot getting worn out quickly when tweaking these display values or (what I'll be doing!) configuring the kernel command line args...

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

Re: config.txt

Mon Feb 13, 2012 10:47 am

The SD card slot is pretty robust. One of the reasons of choosing SD over microSD was its robustness in comparison.
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."

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

Re: config.txt

Mon Feb 13, 2012 11:01 am

Note that you can access the fat partition from linux so you should only need to pull the card out when you mess things up not for every change you want to make.

User avatar
teh_orph
Posts: 346
Joined: Mon Jan 30, 2012 2:09 pm
Location: London
Contact: Website

Re: config.txt

Mon Feb 13, 2012 11:54 am

Yes that's a good point. I do expect to be endless rebuilding the kernel though...so if that can be sent over serial too that would be *amazing*! (although pretty slow too)

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

Re: config.txt

Mon Feb 13, 2012 11:57 am

Serial?  Why not Ethernet?
The key to knowledge is not to rely on people to teach you it.

NAB
Posts: 32
Joined: Wed Sep 14, 2011 6:52 pm

Re: config.txt

Mon Feb 13, 2012 8:56 pm

It's nice to be able to do this, but am I right in understanding that this means you should always check any SD card image you download/get from a friend/otherwise acquire to ensure that it doesn't contain a config.txt file with those overvoltage lines which will void your warranty? Now I'm happy doing this, but I can imagine a lot of people wouldn't be - especially that since by the time they've got the skills/knowledge to know how to check and what to check for, it'd be too late.

In fact, the more I think about it, the less happy I am that somebody could void the warranty on my RPi simply by typing a couple of lines into a config file.

Or maybe I am just completely misunderstanding things...

Nicholas.

TonyHoyle
Posts: 25
Joined: Thu Nov 24, 2011 3:34 pm

Re: config.txt

Mon Feb 13, 2012 9:14 pm

Indeed.. in a school especially... 'hey checkout this new demo'.  Bye bye warranty.

Even worse if someone manages to make a config that can break stuff (massive overvoltage + overclock simultaneously for example).

kasperl
Posts: 90
Joined: Fri Jan 06, 2012 6:20 pm

Re: config.txt

Mon Feb 13, 2012 9:17 pm

Especially since it's a FAT partition, if voiding the warranty is a real option, the Foundation should make sure that the partition not mounted read/write by default in any default image. At least root privligees would/should be needed to void someones warranty.

But yes, that remains a good point. I can't see a solution, and I'm kind of stuck between agreeing with the issue and the position of "if they're executing stuff with full privileges, they own the hardware anyway". I don't think that is a very friendly option, but it does have a point...

(Apologies for typo's, the letters appear about 15 seconds after being typed, and I can't spell check it all afterwards.)

Return to “General discussion”