Crafting the ideal config.txt for RPi
Pages: 1 2
Steve Revill (20) 1361 posts |
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! :) |
Richard Firth (1695) 4 posts |
Maybe a default 192:64 memory split between the system and GPU? 128:128 seems a bit unnecessary for the average RISC OS user. |
Eric Rucker (325) 232 posts |
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.) |
Steve Revill (20) 1361 posts |
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:
|
Jeffrey Lee (213) 6048 posts |
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!) |
Jess Hampshire (158) 865 posts |
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: |
Steve Revill (20) 1361 posts |
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. |
Theo Markettos (89) 919 posts |
With the new firmware we have complete control over GPU split in config.txt: I’d agree that 64MB GPU RAM is sufficient. So a new set of firmware files and a 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. |
Chris Gransden (337) 1202 posts |
‘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. |
Rick Murray (539) 13806 posts |
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. |
Steve Revill (20) 1361 posts |
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? |
Chris Gransden (337) 1202 posts |
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. |
Steve Revill (20) 1361 posts |
That’s exactly how I created the contents of this FAT partition. |
Steve Revill (20) 1361 posts |
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. |
Theo Markettos (89) 919 posts |
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. |
Chris Evans (457) 1614 posts |
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. Proved very helpful! |
Rick Murray (539) 13806 posts |
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… |
Stephen Unwin (1516) 153 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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, The bleeding edge (i.e. occasionally broken) boot files can be fetched from the Raspberry Pi firmware github |
Chris Hall (132) 3554 posts |
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? 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:
|
Rick Murray (539) 13806 posts |
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. |
Jess Hampshire (158) 865 posts |
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.) |
Steve Revill (20) 1361 posts |
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? |
Jess Hampshire (158) 865 posts |
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. |
Steve Revill (20) 1361 posts |
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? |
Pages: 1 2