Crafting the ideal config.txt for RPi

Hi. I’m just looking at updating the FAT partition contents in the official RPi distro and I’d like your views on a couple of things:

1. I’ve been reading that people think it’s wise to have all the files in the FAT partition in 8.3 uppercase names due to a DOSFS bug – is that correct?

2. assuming the latest firmware, what’s the ideal config.txt?

The for the second question, I don’t really want to assume anything about the user’s setup (other than our default screen mode when the distro is first booted should be 1920×1080 @ 16M colours) so I’m not asking for a “let’s put every possible option in there” list; all I really want is the bare essentials – e.g. getting the ARM/GPU memory balance right with the new start.elf and getting the overscan issues sorted. Am I right in thinking the latest BCMVideo means I don’t need the disable_overscan=1 line any more?

I’m only going to collate answers this evening – anything after that will be too late! :)

Maybe a default 192:64 memory split between the system and GPU? 128:128 seems a bit unnecessary for the average RISC OS user.

The default GPU memory is 64 MiB for Linux images, it seems. I’d say that’s a good sane default, especially given that you’d have to really try to max out 192 MiB RAM. (That said, I’m currently using the 224 MiB start.elf, but even for what I’m using it for, that’s complete overkill – even the 128 MiB start.elf was fine.)

Guys, unless I’m mistaken, the latest firmware doesn’t have different start.elf flavours. So I’m asking what, if anything, needs to go into config.txt to override the defaults if there’s some critical reason to do so (i.e. not doing so will cause big problems). I also want to ensure we’re supporting both 256MB and 512MB RPi hardware out of the box.

As I understand it, people weren’t happy with our 128/128 split. Fair enough. If the latest start.elf has a better default, then we can leave it at that.

We had to add the disable_overscan=1 line because of bugs in the firmware and a related lack of functionality in the RISC OS video driver. I’d like to remove that line if that’s sensible at this point.

I’m assuming we still need/want the fake_vsync_isr=1 line, so right now, I reckon our config.txt will look like:

  fake_vsync_isr=1

  kernel=RISCOS.IMG

We had to add the disable_overscan=1 line because of bugs in the firmware and a related lack of functionality in the RISC OS video driver. I’d like to remove that line if that’s sensible at this point.

Yes, overscan should be working properly with the latest ROM. (It was more of a ROM bug than a firmware bug… although the firmware using two different coordinate spaces for the mailbox framebuffer and the dispmanx overlays didn’t really help!)

(other than our default screen mode when the distro is first booted should be 1920×1080 @ 16M colours)

I’m not sure that’s a totally good idea, judging from the fact that several people have posted in the support forum using composite video or eve a VGA adaptor.

Split:
For 1920×1080 you only need 32 M video RAM.
For 1920×1200 it may need 64M

I’m not sure that’s a totally good idea

This decision is beyond debate. All the artwork is done, all the documentation, all the pinboard layouts, blah, blah. The RPi is supposed to be connected to a full HD display and that’s what we’ve set the distro up for. And if your monitor can’t support it, the GPU will rescale the RISC OS desktop very nicely. People who do not have, or cannot obtain a display with HDMI or DVI input that can run at (or close to) 1080p must be few and far between nowadays – and we’re not really aiming this distro at that market segment. Having said that, if there are additions to the config.txt which will assist users of displays incapable to 1080p, who somehow can’t reconfigure the screen mode after it first boots, then I’m all ears, but keep in mind we don’t want to cripple the experience of the majority to satisfy the minority.

With the new firmware we have complete control over GPU split in config.txt:
gpu_mem = ... – for all boards
gpu_mem_256 = up to 192 – 256MB version
gpu_mem_512 = up to 448 – 512MB version

I’d agree that 64MB GPU RAM is sufficient. So a new set of firmware files and a gpu_mem should be all that’s needed. I don’t see any particular need to offer more GPU RAM on the 512MB version, but it’s possible if we need it.

One other issue (already appeared on the RPi forums) is people bringing their old config.txt over (from Linux or previous RISC OS distro) and finding it won’t work. There seems to be a particular problem with overscan and mouse pointer positioning.

‘gpu_mem = 40’ seems to be the minimum requirement for 1920×1200.

The Alpha distro ‘config.txt’ has ‘init_emmc_clock=100000000’. Adding this almost doubles the speed of read/write sequential access with all the SD cards I’ve tried.

but keep in mind we don’t want to cripple the experience of the majority to satisfy the minority.

What is a surprise is that there’s no mechanism to detect what sort of display device is in use “on the fly” and configure automatically.

Also, 1080 is Full HD. If/when I get a digital-capable TV in the new year, it most likely will not be FullHD. The big ones are pricier, basically. But then I’ll be able to make more use of Pi and Beagle; for analogue video, while useful, isn’t the simplest way to use something.

Right. Whatever I do, I cannot get RISC OS to say it’s got anything other than 128MiB of RAM. Note, this is an old 256MiB RPi. This is where I’m at thus far (and I’m pretty sure it’s the latest firmware):

[srevill@srevill-laptop] FAT $ md5sum *
a990c6bcb62a26880609b805ca9e71bb  BOOTCODE.BIN
67c1224a0400a906292168d10c673295  CONFIG.TXT
e86e693d19572ee64cc8b17fb062faa9  LICENCE.BROADCOM
a717a70a39f2f7988a5f918bc39eb9a0  RISCOS.IMG
34aeb384ad252876111a68005d63847c  START.ELF

[srevill@srevill-laptop] FAT $ ll
total 4704
-rw-r--r-- 1 srevill srevill   17764 2012-10-31 20:04 BOOTCODE.BIN
-rwxr-xr-x 1 srevill srevill      72 1979-12-31 23:00 CONFIG.TXT
-rw-r--r-- 1 srevill srevill    1447 2012-09-27 12:15 LICENCE.BROADCOM
-rwxr-xr-x 1 srevill srevill 2433024 1979-12-31 23:00 RISCOS.IMG
-rw-r--r-- 1 srevill srevill 2352536 2012-10-31 20:04 START.ELF

[srevill@srevill-laptop] FAT $ cat CONFIG.TXT 
fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

Is there a recent Kernel/HAL tweak that is required which isn’t in the stable ROM build?

Is there a recent Kernel/HAL tweak that is required which isn’t in the stable ROM build?

I had a similar problem with the latest development rom. I copied all the files away. Deleted everything then copied the files back again. Making sure all the file names were in capitals first.

Deleted everything then copied the files back again. Making sure all the file names were in capitals first.

That’s exactly how I created the contents of this FAT partition.

OK. I just did it again, this time including “FIXUP.DAT” (not sure if that’s even relevant) and it’s all looking fine. How odd.

You do need fixup.dat. If there’s ever any intention of running at 16MB GPU mem you also need fixup_cd.dat and start_cd.elf, as those are the cutdown firmware without OpenGL linked. The boot process (bootcode.bin) will pick which one to use depending on the gpu_mem setting.

What is a surprise is that there’s no mechanism to detect what sort of display device is in use “on the fly” and configure automatically.

AIUI If the GPU doesn’t detect an HDMI connection it assumes Composite. How easy it is for RISC OS to find that out I don’t know.

If 1920×1080 is going to be assumed then for lesser displays (I’ve tried a number that are impossible to see well enough the desktop to change screen setting) can I suggest some easy way of changing to a much lower res mode.
When testing monitors that wouldn’t do 1920×1080 I resorted to putting an obey file called ‘28’ inside Library (or was it Utils) that had *wimpmode 28.
So: F12
28
Return
Return

Proved very helpful!

You do need fixup.dat. If there’s ever any intention of running at 16MB GPU mem you also need fixup_cd.dat and start_cd.elf,

Are these files available together someplace for download? I had to look all over the place to find the “arm192_start.elf” file to install…

My setup is full HD TV, Cheapest on offer at the time from Argos. 24" Bush something or other. Raspberry Pi from Farnell, 256Mb delivered by end of July.
With the following files and TV menu, Picture, Adavnced, Picture Zoom, set as full, I get a perfectly filled screen, to the edges but not over.

A different story when I tried Composite through SCART with the same hardware.
Removing “Disable_Overscan” resulted in smaller desktop and black border. TV Menu options were not able to correct this to fill the screen properly.

You do need fixup.dat. If there’s ever any intention of running at 16MB GPU mem you also need fixup_cd.dat and start_cd.elf,

Are these files available together someplace for download? I had to look all over the place to find the “arm192_start.elf” file to install…

The bleeding edge (i.e. occasionally broken) boot files can be fetched from the Raspberry Pi firmware github

1. I’ve been reading that people think it’s wise to have all the files in the FAT partition in 8.3 uppercase names due to a DOSFS bug – is that correct?

2. assuming the latest firmware, what’s the ideal config.txt?

Regarding 1. there is a sublety that means that non-upper case names will work if you are copying a lower case named file over a file (that might be shown in lower case but is in 8.3 format) as RISC OS preserves the capitalisation of the already existing file over the one being copied over it where the names are otherwise identical. If you are copying the file after the original has been deleted then it WILL need to be in upper case [due to a bug in DOSFS]. The fact that ‘bootcode.bin’ is now used throughout means that the more sophisticated file handling of the previous ‘loader.bin’ [which is not now required] is not available – only 8.3 format filenames are now recognised when looking for ‘start.elf’ and ‘riscos.img’ (possibly also ‘config.txt’ and ‘fixup.dat’). If the filenames are in 8.3 format (not all filenames of this length are actually in 8.3 format if created using DOSFS), it doesn’t matter whether they are in upper or lower case [this is only relevant where the files are copied on other operating systems]. I think that’s complicated enough…

2.add ‘gpu_mem=32’ to the config.txt in RC5 and use the latest ‘start.elf’, ‘bootcode.bin’ and ‘fixup.dat’. If you include any ‘hdmi_xxx’ type lines then it will have the effect of suppressing composite video even if no HDMI monitor is connected. However there’s no harm in documenting what you do include using ‘#’ for example:

#to use with a data projector remove the '#' in the two lines below
#hdmi_group=1
#hdmi_mode=4
#other group-mode selections:
#1-4:  720p60Hz = 1280x720
#1-19: 720p50Hz = 1280x720
#1-17: 576p50Hz = 1024x576
#2-35: 1280x1024 60Hz
#2-51: 1600x1200 60Hz
#hdmi_drive=2 is reqd for group 1 for sound over HDMI
#hdmi_drive=2
#arm_freq=800

Removing “Disable_Overscan” resulted in smaller desktop and black border. TV Menu options were not able to correct this to fill the screen properly.

This is what I get, but given the partly fuzzy, off-the-left-of-the-screen mess that I got with the disable_overscan, I figured a smaller stable display was better than a larger wonky one.

People who do not have, or cannot obtain a display with HDMI or DVI input that can run at (or close to) 1080p must be few and far between nowadays.

The backgrounds work fine at a lower definition. The pinboard doesn’t (it doesn’t even work on an Atrix Lapdock). I was surprised at how many people are using the Pi with composite or low resultion monitors, until I compared the price of a Pi with that of an HD monitor.

Any old hands at RISC OS will have no issues sorting the default into something that works properly, but it could confuse newcomers (and has).

(For reference I have 6 displays that are electrically compatible with the Pi. None are 1920 × 1080, two are higher, and two ought to produce a display that is legible enough to change to the right mode. The other two require F12, wimpmode 28.)

Jess, when you say the pinboard doesn’t work at lower resolutions, do you just mean some of the icons end up off-screen? You do know you can move them don’t you?

Correct. and I know I can move them (and have them lined up at the bottom). But I’m thinking from perspective of a new user, with a screen with lower vertical resolution, who may not know how, and may not even know they are sitting off screen.

I’m not asking this to be inflamatory – it’s a genuine question. No monitor that I’ve connected to my RPi looks sufficiently bad that I can’t read stuff on the desktop (with the GPU resizing it). Now, I’ve been using either HDMI or HDMI to DVI as the connection. I’ve tried various displays: 1280×1024, 1600×1200, 1920×1080, 1920×1200 and they all look fine. How are people ending up (without modifying config.txt – which implies more than enough technical competence to move some pinboard icons) with a display which is so tiny that the thing is unusable?