Boot menu to choose distro and/or memory model of choice.

[mahjongg]

As is slowly becoming more well known, the RAM of the R-PI is shared between the ARM CPU and the GPU, and the R-PI can use three different "memory models", that is splits of the 256MB RAM, the three possible splits are:


224MB RAM and 32MB VRAM for a Linux desktop distro, or a heavy (non GUI) applications that don't need to play video, nor render 3D.
192MB RAM and 64MB VRAM (default) for desktop distro's that want to play video or have 3D effects.
128MB RAM and 128MB VRAM for applications and games that do extensive multimedia or play 3D rendered games.

Currently the only way to switch to another memory model than the default is to change a text entry in the config.txt file. So an "image" for a specific distro that needs for example to do heavy multimedia, or 3D will come with a pre-defined config.txt file.

But SD cards as big as 32MB will soon be common, and people will probably want to put applications/games/distro's on a single SD-card that need/want to operate with different memory models, so there is a need to change the memory model (and boot the corresponding software) without manually having to modify config.txt.

Therefore I propose that R-PI distro's use a "boot menu", (similar to those used on live_CD's) that make it possible to choose between booting the three possible memory models (GPU/CPU RAM sizes splits of 32/224 MB, 64/192MB and 128/128MB) with three different (corresponding) distro's, one distro for "full desktops" without multimedia, one for distro's with light multimedia, and one distro (or stand alone application) for running games or other heavy multimedia applications (think XBMC) needing 128MB of GPU RAM. The same bootmenu could then also check if other partitions with applications/games/distro's are present, and if present include it in the menu.

Possibly any applications/games/distro's should come with a text file that contains which memory model(s) are supported, or necessary for it, so that the boot menu can start the right on, or give a choice if a choice is available.

[SN]

I'm guessing this can't be grub or lilo or similar as its the gpu that reads the config file and grabs the memory its told to for itself before setting the cpu on its merry way...

[mahjongg]

SN said:


I'm guessing this can't be grub or lilo or similar as its the gpu that reads the config file and grabs the memory its told to for itself before setting the cpu on its merry way...


No the R-PI is unique, so it needs unique tools, that doesn't mean code from GRUB or LILO cannot be adapted, but you are right, the code should:

Scan the partitions for bootable content

read the text file of each bootable content (if it exists) to see which memory models(s) it supports.

Present its findings in a menu, and create the relevant choices.

Adapt config.txt (if needed for booting)

boot the right partition with the right memory model (blob), here is where LILO or GRUB code could be re-used.

[jojopi]

Boot menus are annoying. They either slow things down too much, or on the rare occasion you need them you are at risk of missing the timeout.

Why not just have a script that changes config.systxt and cmdline.txt and then reboots, if you expect to do this a lot.

[Joe Schmoe]

+1

That's my sense, too.  That it is an infrequent enough operation that you should just be able to provide an app to do it and then reboot.

Remember, that the Pi is rumored to be a speed demon booting, so there should be no objections on that account.

[andri]

Sorry for my english.

I think it's easier to put each config on each SD Card.

SD Card is cheap so I can have different SD Card for each config.

I remembered when we use floppydisk with different CONFIG.SYS to boot.

It's more easier (and faster) than use multiboot, just swap the SD Card.

[SirLagz]

But then you would either need to keep files that you wanted to use all the time on all the SD cards, or on another form of external media i.e. network / usb hdd

I would rather a script run to change configs / some sort of menu.

Script would be easy to do in shell script, as you could just rename files or overwrite the current config.txt file

[SN]

the ONLY flaw with the script that allows you to edit config.txt and reboot is that you could generate an illegal config.txt file and (temporarily) make your raspi unbootable - if you have no other device easily to hand to edit config.txt you have effectively bricked it for the immediate future.

BUT I see this is a minor irritation - so scripting it is then.

Incidentally, here I think, is Opportunity #1 for a Standard raspi Tool - one that plays with config.txt to avoid end user typos/fumblings in vi or whatever - converting all those codes and numbers in to human readable text / pulldowns/ check boxes

[zippy]

A simple boot menu is the kinda thing I'd like to do direct from ARM assembler, but it's not possible yet as there's no documention on how to do basic stuff like put text on screen or read input from the keyboard by hitting the hardware direct.

Hopefully once the RasPi is out there the Linux drivers will be hacked to provide this info and we can really be back in the days of the 8 and 16 bit home computers where stuff like this could be knocked up in assembler in a few hours.

I'm sure all this stuff will come, it'll just take time.

[mahjongg]

One reason I proposed a boot menu is that when you wreck the distro on the card, (it does happen) you could boot into a "recovery" mini distro.

On the other hand, SD-cards are so cheap that you probably would have several, and fast booting is also possible.

Still, I can image that you want to be able to boot a single Linux OS with at least two different memory models, with 32MB of VRAM or 64MB of VRAM, having two different cards for the two versions is also a possibility though. And I can imagine that two dedicated versions for a certain memory model might work better.

[asb]

mahjongg said:


One reason I proposed a boot menu is that when you wreck the distro on the card, (it does happen) you could boot into a "recovery" mini distro.

On the other hand, SD-cards are so cheap that you probably would have several, and fast booting is also possible.

Still, I can image that you want to be able to boot a single Linux OS with at least two different memory models, with 32MB of VRAM or 64MB of VRAM, having two different cards for the two versions is also a possibility though. And I can imagine that two dedicated versions for a certain memory model might work better.


It's easy to reboot in to the memory split of your choice. The /boot partition contains arm{128,192,224}_start.elf and start.elf. Just cp /boot/arm_ARMMEMSIZE_start.elf to /boot/start.elf and reboot. It's trivial to have a script to this for you, and detect the current memory split.

[pepedog]

mahjongg said:


Currently the only way to switch to another memory model than the default is to change a text entry in the config.txt file. So an "image" for a specific distro that needs for example to do heavy multimedia, or 3D will come with a pre-defined config.txt file.


Not quite so.

There are 3 start.elf files, you rename desired to what you want

cp /boot/arm192_start.elf /boot/start.elf

[SirLagz]

SN said:


the ONLY flaw with the script that allows you to edit config.txt and reboot is that you could generate an illegal config.txt file and (temporarily) make your raspi unbootable - if you have no other device easily to hand to edit config.txt you have effectively bricked it for the immediate future.

BUT I see this is a minor irritation - so scripting it is then.

Incidentally, here I think, is Opportunity #1 for a Standard raspi Tool - one that plays with config.txt to avoid end user typos/fumblings in vi or whatever - converting all those codes and numbers in to human readable text / pulldowns/ check boxes



I was thinking shell script to keep it nice and simple.

I haven't explored config.txt all that much, but I imagine it wouldn't be too hard to manipulate individual strings inside the file to suit the needs of the user.

[rew]

The normal way that a boot menu works is that it presents the menu and then sets the CPU on its merry way booting whatever selection was made.

However, with the RPI this is slightly more difficult: the GPU will read the config.txt file and the fist instruction on the ARM is executed with the memory model that config.txt selected.

So the only remaining possibility is to "reboot" the GPU after changing config.txt. After debugging such a menu program, that should be reliable enough.Question is: can we get the GPU to reboot from ARM software?

[dom]

"sudo reboot" from ARM will reboot the GPU and config.txt will be re-read.

[naicheben]

I can't find anything usefull on the wiki regarding config.txt and the selected image

I will rely on asd and pepedog. config.txt is for fine tunig and to match your needs depending resolution, PAL/NTSC and Overclocking. I don't see anything like changing memory model there... http://elinux.org/RPi_config.txt

[mahjongg]

naicheben said:


I can't find anything usefull on the wiki regarding config.txt and the selected image


No, it was my misunderstanding too that the GPU would read config.txt and from that would conclude which of the three start.elf files (blobs) it would start;

arm224_start.elf

arm192_start.elf

or

arm128_start.elf

but that isn't true. the GPU simply always starts "start.elf"!

The user itself has to make sure that the right .elf file is copied to start.elf

So there are actually four "$start.elf" files on the SD-Card, not three. One of them is a copy of another (which is a bit of a shame, space efficiency wise, but so it is).

This is a bit of a problem for people who do not have a full PC with a SD-Card reader, but there are more reasons than that why at the moment the R-PI is more or less dependent on another PC.

What if you have no other PC to change the SD-Card with. Can you still copy one of the three arm*.elf files to start.elf, does Linux allow you to do that? I assume it does, but its a bit bothersome and error prone, to boot up Linux, copy the blob of your choice to boot.elf, then reboot, and what if the chosen blob leaves not enough memory to boot up with? Then you have "painted yourself into a corner", as you cannot change back to a useable blob again (without using another device to change the SD-Card).

What if the distro you boot with is for any other reason corrupted, and you cannot boot anymore, not even the "debugging boot option" I heard exist.

That is where a boot menu system would come in handy, even if it delays the booting process a fraction of a second it would be handy to have a way to break into the booting process somehow, and be given the possibility to do some basic things to recover from a non booting situation. Or the possibility to change the memory model (blob that is loaded).

I do realize that to stop the booting, the keyboard has to work, and that means that the USB stack must have been loaded, and is working!

[SirLagz]

Only need the 3 files, assuming they don't get corrupted.

Just rename the one that you need. The script can then work out which one is currently being used by checking the other 2 and seeing which one is missing.

As for the Distro issue, you could always have a script that runs on each and every startup to check if the previous start-up was successful, if not then rename the current start.elf to what it's mean to be and copy the arm224_start.elf to start.elf and reboot. That way it's sort of a failsafe so you could hopefully recover if you do copy the wrong start.elf file and can't boot into the GUI.

[naicheben]

RS and element14 will offer bundles, so you can go using the pi without having a PC. Maybe the shops will sell a bundle including a USB-SD-Cardreader and a extra SD Card so you can have one SD Card for recovery and the other one to "destroi"

Well at least you can buy it in every electronic store you like.

[mahjongg]

Well, yes, but unfortunately you also need a (powered) USB hub, because (unless your keyboard has a USB hub built in, and you can connect the mouse to the keyboard) to connect the cardreader you need a third USB connection, beyond the raspberries own two.

Also, all the USB devices together may draw just 100mA or so, I do not think its enough to power mouse, keyboard and cardreader together.

[naicheben]

No, the Recovery-SD-card is in the SD-CCard-Slot, then you have 2 USB: 1 Keyboard, 1 USB-SD-cardreader.

My PSU is 5V/1A. No problem with the power. Model B only uses MAX 700mA. Normal operation (console only) will draw much less than 700mA.

[mahjongg]

Ah, so you assume a console application, not a GUI one (which needs a mouse).

The PSU isn't the issue, the issue is that the R-PI's USB ports are fused with a 100mA fuse, not sure what the SD-card reader needs, when writing the card, but together with the keyboard it -might- be an issue.

actually having just one permanent blob for a single card might be fine for most applications, but I can imagine a linux distro that you sometimes want to run with 32GB of Video RAM, and sometimes with 64 GB, what do you do then, use two different SD-cards?

I also think that the raspberry pi should be self supporting, without adding massive to its cost.  A single card writer might be acceptable (adding a few dollars to the cost of the basic setup) but powered USB hubs might be a lot costlier, I'm not taking about myself here, Im talking about second and third world kids.

[SirLagz]

mahjongg said:


Ah, so you assume a console application, not a GUI one (which needs a mouse).

The PSU isn't the issue, the issue is that the R-PI's USB ports are fused with a 100mA fuse, not sure what the SD-card reader needs, when writing the card, but together with the keyboard it -might- be an issue.

actually having just one permanent blob for a single card might be fine for most applications, but I can imagine a linux distro that you sometimes want to run with 32GB of Video RAM, and sometimes with 64 GB, what do you do then, use two different SD-cards?

I also think that the raspberry pi should be self supporting, without adding massive to its cost.  A single card writer might be acceptable (adding a few dollars to the cost of the basic setup) but powered USB hubs might be a lot costlier, I'm not taking about myself here, Im talking about second and third world kids.


Console is the way to go. Makes things simpler.

32GB of Video Ram hey ? sometimes 64GB ?

I would love to have that much Video Ram

Chances are when I get my Pi, I'll be swapping between modes a bit so I will probably work up a script to rename the blobs. It will be a shell script, not a GUI program so that it can be run via either GUI or shell.

[mahjongg]

well yes, if you can boot into the shell you can run a script to change the video ram size to 32, 64 or even 128MB, then reboot. Its just that this is a time consuming way to do it (booting two times even if its only to the console).

A boot menu would also open up the possibility to boot another partition, or even a rescue partition. If you have stuff on a SD-Card and you cannot boot it, you will need an external SD-Card reader, and quite often thus also a USB hub, unless you want to forego the GUI, which for most people isn't an option.

Its a pity the R-PI doesn't have two SD-cards, but that is the consequence of doing everything to keep the price down.

[jamesh]

SirLagz said:


mahjongg said:


Ah, so you assume a console application, not a GUI one (which needs a mouse).

The PSU isn't the issue, the issue is that the R-PI's USB ports are fused with a 100mA fuse, not sure what the SD-card reader needs, when writing the card, but together with the keyboard it -might- be an issue.

actually having just one permanent blob for a single card might be fine for most applications, but I can imagine a linux distro that you sometimes want to run with 32GB of Video RAM, and sometimes with 64 GB, what do you do then, use two different SD-cards?

I also think that the raspberry pi should be self supporting, without adding massive to its cost.  A single card writer might be acceptable (adding a few dollars to the cost of the basic setup) but powered USB hubs might be a lot costlier, I'm not taking about myself here, Im talking about second and third world kids.


Console is the way to go. Makes things simpler.

32GB of Video Ram hey ? sometimes 64GB ?

I would love to have that much Video Ram

Chances are when I get my Pi, I'll be swapping between modes a bit so I will probably work up a script to rename the blobs. It will be a shell script, not a GUI program so that it can be run via either GUI or shell.


Note that the 32/64GB whatever allocation is total memory allocated to the GPU- not just frame buffers. So depending on what you want the GPU to do, you need to allocate different amounts. For example, just a frame buffer? 3GB more than enough. H264 decode? Need more? Camera? Need even more.