Request: Bootloader

[elatllat]

Something like GRUB or moboot would improve the raspberry-pi significantly.
That or more ram, or dynamic memory allocation for the GPU ( not realistic
a boot loader would let people use a light weight embedded OS for standalone GPU intensive tasks (xbmc, games,etc) and heavy full featured OS for integrable 2D or CLI tasks.

I believe a bootloader for raspberry-pi is doable because there are FOSS arm bootloaders (moboot) and the GPU memory allocation choice point is in start.elf on the partition. The only problem would be if we don't have the source for the part that retrieves start.elf (likely). Maybe kernel.img could me made to chain-load avoiding the black GPU blob. Maybe there is a hidden feature of config.txt.
Maybe related https://github.com/dwelch67/raspberrypi .

Anyway if anyone is interested or knows where to start please chime in.

[patrikg]

U-boot ??

http://kernelnomicon.org/

[mahjongg]

Any bootloader should on the fly edit the contents of the /boot directory of the Sd-card, then do a reboot. Conventional bootloaders do not work on a R-Pi.

[ailwyn]

Conventional bootloaders do not work on a R-Pi.

Why? (genuine question)

My understanding of a bootloader such as grub is it is loaded at startup and this provides a menu then to start any kernel you like (providing it can access it) - please correct me if I'm wrong.

If you created your "grub" and called that kernel.img then that would get executed by the gpu/binary blob/whatever and from there it could load the actual kernel you want, wouldn't it? Am I seeing this in too simplistic a way?

Thanks

Ailwyn

[chrisw2]

... Conventional bootloaders do not work on a R-Pi.

Have you looked at the link patrikg posted above?

Maybe you don't classify u-boot as a "conventional bootloader"? but to me that looks like a working bootloader even if it probably needs more work doing to add support for HDMI output (the developer, Gonzo is using a serial terminal, I think)

[mahjongg]

Why I think it doesn't work as on any normal PC, it because the R-Pi isn't a normal PC!
For one, it doesn't have a normal BIOS, so it doesn't do a normal boot-sequence.
Then it reads a text file at boot time and uses parameters from it, (parameters I hope could be selectable at boot time) even before executing any ARM code (AFAIK)!

I would love it if it was possible to get a universal boot system that would:

• Enable the selection of a memory split at boot time
• Enable the choice of a partition to boot from, when there are multiple bootable partitions on the SD-Card.
• Enable the choice of another medium (USB stick, Harddisk) to boot from instead of just the SD-card
• Choose alternative video settings, (alternative resolutions, PAL instead of NTSC etc) at boot time
• Boot into specialised tools instead of normal booting (for example a RAM based distro that would not use the SD-card, so the SD-card would be fully format-able and writable

AFAIK none of the existing (classic if you will) bootsystems would work on the R-Pi, in fact except for the existing boot method, there seemed to be no alternatives. The existing bootsystem would give us none of the above options.

Now there is a completely new "boot system", that has a conventional name, (u-boot) but this version seems to be written from the ground up, no idea yet if it does one of the above, more than one of the above, or none of the above, or what its Raison d'être is

In fact months ago I expressed the wish for a better boot system, but was told, "it isn't possible, because the R-Pi doesn't and cannot use conventional bootloaders", amongst other reasons.

See: http://www.raspberrypi.org/phpBB3/viewt ... =24&t=4691

I hope that was wrong! It would make me very happy.

[elatllat]

uboot seems to work.
At least partially because it shows me a nice image after boot.
It does not give me a menu though.
The text files in the image don't give me any insight on how or if it should be configured.
Unless there is some documentation I missed the next step would to to read the source of u-boot.bin or ask the author.

> blkid |grep /dev/sdg
/dev/sdg1: UUID="29D0-92A9" TYPE="vfat" SEC_TYPE="msdos" LABEL="boot"
/dev/sdg5: LABEL="debianarm" UUID="18c27e44-ad29-4264-9506-c93bb7083f47" TYPE="ext4"
/dev/sdg6: LABEL="openelec" UUID="e6a40a83-91e3-476c-bb5f-13ed9323d667" TYPE="ext4"
/dev/sdg7: LABEL="raspbmc" UUID="abc877f1-c63b-4195-b8e6-1a29f131ddec" TYPE="ext4"
/dev/sdg8: LABEL="Raspbian" UUID="00d7fb0c-6d74-4f57-be30-3b27584fc4d3" TYPE="ext4"
/dev/sdg9: LABEL="swap" UUID="9207a855-e2fa-4c9f-aeb7-d43e3570267a" TYPE="swap"
/dev/sdg10: LABEL="share" UUID="9f3ce8ba-8cd3-4bde-ac55-18117df871dc" TYPE="ext2"
>mount /dev/sdg1 /media/USB_HD/
> tree /media/USB_HD/
/media/USB_HD/
├── bootcode.bin
├── boot.scr
├── cmdline.txt
├── config.txt
├── loader.bin
├── scripts
│   ├── boot.cmd
│   ├── boot-mmc.cmd
│   ├── boot-mmc.scr
│   ├── boot.scr
│   ├── boot-tftp.cmd
│   ├── boot-tftp.scr
│   └── readme
├── start.elf
├── u-boot.bin
└── uEnv.txt

1 directory, 15 files

[elatllat]

I tried:

Code: Select all

cp /media/USB_HD/scripts/boot-mmc.scr /media/USB_HD/boot.scr

because these files are the same:

Code: Select all

/media/USB_HD/boot.scr
/media/USB_HD/scripts/boot.scr 

but the compiled version of:

Code: Select all

if mmc rescan start; then
    if fatload mmc 0 ${loadaddr} uImage; then
        go 0;
    fi;
fi;

made no difference.

u-boot.bin is only 226K and the numlock on the keyboard did not work so this might be a non interactive, jtag or serial boot loader....
cmdline.txt is interesting:

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait

so maybe I just need to fix cmdline 0 then replace it and reboot when I want a different OS.....

[Max]

My understanding of a bootloader such as grub is it is loaded at startup and this provides a menu then to start any kernel you like (providing it can access it) - please correct me if I'm wrong.

Problem is that by the time the boot loader is loaded, the memory split can no longer be changed.
At least not without changing the start.elf GPU firmware on the FAT partition and rebooting. Posing a problem as the average bootloader knows just enough about file systems to read from them, not to write to them.

Each operating system has different memory needs.
e.g. OpenELEC/XBMC will not work with anything other than the 128 MB split.
And some other OSes like OLPC's Sugar need the 224 MB split, or they swap so much, they are practically unusable.

An alternative would be to write a boot selection menu that runs under Linux, which I plan to do, but currently haven't had time for to implement properly.

[elatllat]

I got a nice email from the uboot auther:

Unlike GRUB U-Boot is not really suitable for the kind of user interaction
you're trying to implement. It communicates with user only over serial port.
With some efforts you can implement frame buffer support and add USB keyboard
driver. But I doubt upstream U-boot will ever accept these changes.

Source code for the project is located at
https://github.com/gonzoua/u-boot-pi/tree/rpi

Official U-Boot site: http://www.denx.de/wiki/U-Boot/

I think adding a script to each install would be less work than adding drivers/features to uboot...
maybe the script could do something crazy simple like change the order of the partitions in in MBR, but that might not work for extended partitions.
It will be a pain to add tools with lots of dependancies to the embedded OSs....
rewriting the first partition is worth a try.

[elatllat]

Simple test script:

Code: Select all

#!/bin/bash

ls -1 *.img |nl
echo -n "select a number:"
read ANUM
IMG=$(ls -1 | head -n $ANUM | tail -n 1);
if [ "$IMG" == "" ]; then
	echo "Unknown option ($IMG)"
	exit -1
fi
echo -e "Copy $IMG to /dev/mmcblk0p1\n[Ctrl]+[C] to cancle, or [Enter] to continue?"
read YNM
dd bs=1M if=$IMG of=/dev/mmcblk0p1;
shutdown -r now

for each distro you need to edit the cmdline.txt to point to the correct partition,
dd it to distro-name.img in the same dir as the script,
copy the script dir to the ext partition of each distro.

This script "bootreloader" idea works, but not for extended partitions limiting you to 2 distros if you have a swap partition.
I think that limitation is in the kernel.img but maybe not as the partition is in cmdline.txt which is common to all rpi distros so it might be a bcm limitation.
can someone comment on the extended partition limitation?

[itimpi]

Not seen any limitations with extended partitions. I have partition 4 as an extended partition, and then in that logical partitions (which start with numbers from 5 upwards).

[elatllat]

so booting from extended/logical partition:
debianarm=fail
openelec=pass
raspbian=pass
raspbmc=pass (I think the autoupdate failed due to the non-default partitions but I'm not sure )

[itimpi]

so booting from extended/logical partition:
debianarm=fail
openelec=pass
raspbian=pass
raspbmc=pass

That would tie up with my experience then! I have Debian on a primary partition and other distributions on extended partitions. This was not deliberate - it just happened I suspect that it is not a kernel issue but something hard-coded in the Debian boot sequence.

[elatllat]

So the BootReloader is working nicely,
The only cavet is having to ssh into the xbmc OSs to run the script,
anyone know how to run a bash script from xbmc?

(I have not been able to convince the "advanced loader" xbmc plugin to play nice yet)

[elatllat]

All it needed was a sudo

now there is a nice "reboot to raspbian" in the raspbmc menu.

[hilaryyy]

I like where this thread is going. <3

[owendelong]

I would actually like to be able to choose from more than one available kernel at boot time just for the ability to have a safe (known working) and test (recently compiled) kernel and not have to run back to something with an SD reader to sort things out if the test kernel doesn't boot successfully.

[aselvan]

So the BootReloader is working nicely,
The only cavet is having to ssh into the xbmc OSs to run the script,
anyone know how to run a bash script from xbmc?

(I have not been able to convince the "advanced loader" xbmc plugin to play nice yet)

Thanks @elatllat and others in this thread for all the information here. I only needed 2 distros (i.e. raspbian and raspbmc) and the setup works like a charm!

[jamesh]

Worth adding that dynamic memory splitting between GPU and ArRM is in the latest version (beta?) versions of OS and GPU binary.

[teh_orph]

Worth adding that dynamic memory splitting between GPU and ArRM is in the latest version (beta?) versions of OS and GPU binary.

Yep, you can turn it on with the CMA options in config.txt. Have a look in the wiki. I think this needs the 'next' branch of the kernel and GPU binary though.
It is totally ace and I'm a big fan of it!

[Max]

I think this needs the 'next' branch of the kernel and GPU binary though.

Next branch is default now.
http://www.raspberrypi.org/phpBB3/viewt ... 48#p243148


And yes, CMA seems to works fine.

[MTulio]

Someone managed to show something in screen during boot with u-boot?

If entered in u-boot CLI is possible to create an command to choose how image will load into the memory using readline or other u-boot tool, isn't?

Marco Túlio