some general toolchain, booting and kernel question for the xm

GoogleGroups
1

Hello beagle board group,

I got a beagleboard-xm in the mail a couple of days ago. I was able to
boot the validation image and run some of the test without any issues,
the board is working perfectly as far as I can tell. I want to build
an image myself with my own root file system, but I have some
questions that I'm not able to find the answers to myself.

Booting:
I saw there is a program called X-loader, and a file called uboot on
the validation image.
How do uboot and x-loader differ?
Where are they stored? I'm guessing they are on the SD card because I
read that the xm version has no flash memory. If they are on the SD
card, where can I get just the x-loader and uboot files to install
them without a linux distro?

Here is my partition scheme for my sd card. Can it house an x-loader
and uboot install? The other 2 partitions are for eventual root and
swap space. Do I have to use fat32 for the x-loader and uboot images?

2

Hi Chris,

X-loader is called MLO on your first partition. u-boot is known as u-boot.bin. Embedded systems with constrained resources often use multiple bootloaders, in which early stages initialize the system just enough to load the more capable later-stage programs. X-loader function as a secondary bootloader - after booting from the Beagle’s boot ROM, it initializes memory and then loads the third-stage bootloader U-boot, which initializes all other subsystems and then boots the Linux kernel. U-boot has a shell-like environment - try stopping the boot countdown timer and typing “printenv” at the prompt. Type ? to see all available commands.

On your card, the first partition contains MLO, u-boot.bin, and uImage (the Linux kernel). It should also contain one or more boot scripts (*.scr). The second partition contains the root filesystem, which you can modify if you know how to do so without breaking anything :).

Much of this is explained here: http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext

I strongly suggest you start with a known working system. The validation image that comes with the board is an Angstrom distribution (http://angstrom-distribution.org). You can download all the sources, config files, rootfs, and everything else you might need from that site.

Here is another good place to start: http://www.ibm.com/developerworks/linux/library/l-beagle-board/index.html

3

Here is another good place to start:http://www.ibm.com/developerworks/linux/library/l-beagle-board/index…

But before you go out and buy all those cables, with the xm you can
connect straight from the beagle serial port to normal computer's usb
port with a serial-to-usb cable. You dont need a null modem cable and
all that except for the pre-xm beagleboards
Brett.

4


— On Mon, 10/25/10, Jeff Osier-Mixon jefro@jefro.net wrote:


> From: Jeff Osier-Mixon jefro@jefro.net
> Subject: Re: [beagleboard] some general toolchain, booting and kernel question for the xm
> To: beagleboard@googlegroups.com
> Date: Monday, October 25, 2010, 4:53 PM
>
> Hi Chris,
>
> X-loader is called MLO on your first partition. u-boot is known as u-boot.bin. Embedded systems with constrained resources often use multiple bootloaders, in which early stages initialize the system just enough to load the more capable later-stage programs. X-loader function as a secondary bootloader - after booting from the Beagle’s boot ROM, it initializes memory and then loads the third-stage bootloader U-boot, which initializes all other subsystems and then boots the Linux kernel. U-boot has a shell-like environment - try stopping the boot countdown timer and typing “printenv” at the prompt. Type ? to see all available commands.
>
> On your card, the first partition contains MLO, u-boot.bin, and uImage (the Linux kernel). It should also contain one or more boot scripts (*.scr). The second partition contains the root filesystem, which you can modify if you know how to do so without breaking anything :).
>
> Much of this is explained here: http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext
>
> Some PowerPC systems that use UBoot put the uBoot and the compressed RTOS in Flash and dont use 2 loaders. why was that done here?
> How big is the NAND on my C4 ?
>
> Being a newbie to linux the part I dont fully understand is below
>
> <The second partition contains the root filesystem, which you can modify if you <know how to do so without breaking anything :).
>
> Is the root file system what I see when typing ls from /? and
>
> most importantly does root file system contain an new executeables I install
>
> I am interested in the process to add a command or program to the filesystem
>
> I am guessing you change the root file system and place it on the SD everytime you want to add an executeable?
>
> I see question asking about "i did an apt-get install and its not there after reboot?
>
> Thanks

|

5

Brett is correct. The xM is about US$20 more expensive than the rev C, but you easily save that $20 and more by not having to buy cables, an ethernet dongle, or a USB hub.

(A revised version of that article is slated to be posted on developerWorks in… the near future :slight_smile: )

6

Hi Mark, it sounds like some more basic Linux information is necessary here before diving into bootloaders.

The root filesystem (rootfs) is indeed what you see when you type “ls /” from a working system. It is the head of the device’s filesystem - all other filesystems attached are mounted underneath /. For example, home directories for users are usually set up under /home, and it is possible to set up /home on a different partition and mount it, so that a hardware failure on / won’t take out your personal files. /home still shows up in the same place, even though it is actually a pointer to a different location.

On Linux, as opposed to many other OSes, the rootfs can be separate from the kernel, and thus it can be present in any of several different forms. The most common methods are (1) kernel and rootfs in one partition/filesystem, as with most other operating systems; (2) rootfs in a separate partition, as it is with Angstrom in the system I described below; or (3) rootfs in a compressed file that is expanded into active RAM rather than residing on a physical medium, known as a RAMdisk. The beagle can boot with any of these, but #2 and #3 are most common.

Some systems do away with x-loader by creating a boot ROM that provides the functions X-loader performs, namely initializing memory. Having separate, writable firmware that handles such low-level functions makes the system incredibly flexible, but it does mean an extra step for developers and an extra level of confusion for those new to the system.

It is certainly possible to make changes to the rootfs, write them to the SD card, and reboot. It might be more useful to set up networking on the target itself, though, and use opkg to install software from a repository, as you would with a desktop system. The person who had difficulty with their changes disappearing was probably either using a RAMdisk (which is not saved after the reboot) or was having some other difficulty with installation.

Note that in a production environment, the rootfs is very often NFS-mounted over a network so that the developer can make changes to the running system without swapping cards. This is not a trivial setup, but it can be useful if you are making a lot of changes to the rootfs during production.

I hope this helps! I can recommend a few places to read more about how Linux filesystems work, but the best is Chris Hallinan’s book “Embedded Linux Primer”.

good luck

Jefro

7

I'm trying to use an initramfs (gzipped cpio file) with the Linux kernel
via u-boot. From what I can tell, the only requirement to tell the
kernel about the initramfs is to specify it with initrd= in the
bootargs. The kernel will recognize it as an initramfs. I want the
initramfs as an external file, not compiled into the kernel, so it can
be updated without having to recompile the kernel.

Given that, here is my u-boot boot.scr. Is there any reason why loading
the initramfs into memory first and specifying the memory address to the
initramfs shouldn't work? It works okay if its the real root file
system though in that case the real rootfs is a compressed ext2 image
and not a cpio.gz. My goal is to use the initramfs to mount an external
ext2 rootfs that is on the SD card.

Notes:
The initramfs is a gzipped cpio file. I had used gzip -9 but I'm not
sure that level of compression will work. I plan on trying without -9
tonight when I get home.
The error I see when I try this is that the initramfs can't be found via
NFS! Not sure what I'm doing to make u-boot or the kernel think it's
coming from NFS.

I'm not at the board right now so if you need the exact error message
I'll have to send it off tonight when I get home.

# This boot script loads the kernel and an initial ramdisk
# into memory, then runs them. The initramfs simply switches
# to the root file system on the SD card.
# --------------------------------------------------------
# Setup environment
setenv scriptid ***** Boot using initramfs *****
setenv console ttyS2,115200n8
setenv vram 128M
setenv videomode tv:ntsc
setenv defaultdisplay tv
setenv kerneladdr 0x80200000
setenv ramaddr 0x81600000
setenv mmcargs setenv bootargs console=${console} console=tty0 vram=
${vram} omapfb.mode=${videomode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} initrd=${ramaddr},32M ramdisk_size=32768
run mmcargs
# --------------------------------------------------------
# Start the boot process
echo ${scriptid}
mmcinit
fatload mmc 0 ${kerneladdr} uImage.bin
fatload mmc 0 ${ramaddr} initramfs.gz
bootm ${kerneladdr}

8

I strongly suggest you start with a known working system. The validation
image that comes with the board is an Angstrom distribution (http://angstrom-distribution.org). You can download all the sources, config
files, rootfs, and everything else you might need from that site.

Here is another good place to start:http://www.ibm.com/developerworks/linux/library/l-beagle-board/index…

I can't seem to find the sources for a kernel on the angstrom
website....as silly as that sounds.
Is angstrom the upstream developer of their beagleboard kernel? If
not, who is?

9

hi Jeff,
Looks like you are doin a grt job by helpin out new guys. hope tat u
wud help me too with the uboot woes.
Here is what I am doin:
i wanted to start from scratch. so i built the toolchain, created RFS
using busybox and then the uImage

here is what i copied to the new card's FAT partition:
i copied the MLO file(got it from from the validation MMC card that
was sent with the board)
created uboot.bin(from mkimage tool) and copied it to the new MMC
card.
and then copied the uImage
so copied totally 3 files to the FAT(MLO,uboot.bin & uImage)

however the board doesnt read from MMC when i turn it on.i am
wondering if there are any other files that are to be copied onto the
card or does any of those files require editing? stuck with this for
the past 2 days.i would greatly appreciate your response.

Thanks in advance
Vamsi

10

Hi Vamsi, it sounds like you are at least on the right track.

Is the FAT partition on your card bootable? Meaning, does it have its “bootable” flag set?

Are you using a rev C or rev xM board? Try pressing the USER button while applying power to the system to see if you can get at least the bootloaders to run.

You can also use the “u-boot.bin” and “uImage” from the validation image. Although I imagine you will want to use your own eventually, I suggest that you only make changes one at a time, i.e. get it booting using a known-good set of components first, and then replace each one step by step to see where it breaks. (You will probably never have to change MLO or u-boot once they are working.)

Which toolchain are you using, and where did you get it?

hope this is at least a little helpful!

Jeff

11

hi Jeff,
Thanks for responding.

my board is xM.
Yes, the FAT partition on the new car is bootable.
And abt the toolchain. I built it with buildroot.

I have one more question. Other validations were using .scr file. Is it mandatory to have the file on the card?

Thanks,
Vamsi

12

If you get the u-boot messages at all then check them to see where
u-boot was loaded from. It should be one of the first messages
displayed when power is applied to the board.

On my Ax/Bx board u-boot is loaded by the x-loader from the MMC (re: SD)
card. If you see this and u-boot starts then the board can see the SD
card. That's a good start.

Next comes the u-boot load of the kernel. You don't mention having
copied the boot.scr file to the SD card. The u-boot image from the
validation images uses the boot.scr to determine how to load the kernel
image and root file system. Well, at least it does for the validation
images. So make sure if you're testing with the validation images that
you copied in the boot.scr too.

13

I believe they renamed the uboot.bin to not have the .bin in the latest set of images. for the xm I know it is changed.
I know the xM works with a fat32 as I tried both, and that was what worked.