Hi,
I got the Beagleboard xM a week back and was trying to port the kernel
since then. I am listing what I have done till now
a)Built the toolchain
b)Built the kernel
c)Created the RFS
d)Made the uImage by appending the uBoot header to Kernel image
f)formatted the SD card and made a partition for FAT32 where I loaded
the uImage(i guess using SD card is the only way to boot xM, correct
me if I am wrong)
I cant even my uImage by
transferring it onto RAM cuz the bootloader i got with the board
doesnt support ifconfig command
However the uImage is not being
read when I turn the board ON. I wonder if I have to put some more
files on it. I couldn't find much help regarding uBoot on the web.
Please let me know what else am I missing here. I would greatly
appreciate any help.
Thanks,
Vamsi
See one of these two:
http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidationv2
or
http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
It may just be that you named the file on the SD card incorrectly.
These pages show some of the output you can expect from u-boot when it
tries to load the uImage from the SD card.
Note that these may not be accurate for the xM board. I'm not using one
of those but perhaps this information is not considerably out of sync
given a similar u-boot process.
FYI - u-boot has a home here: http://www.denx.de/wiki/U-Boot
Information about how the u-boot on the BeagleBoards operates is a
little harder to find but you can get a little bit of a clue by looking
at the Angstrom files (see
openembedded/recipes/angstrom/angstrom-uboot-scripts). Essentially, the
u-boot reads a script (a text file run through mkimage to create a
binary file) that has u-boot commands in it. These commands tell u-boot
how to boot the kernel and root file system. From what I can tell, the
default boot script looks something like this (my version, and the
videomode and defaultdisplay are different in the default - they are set
to dvi settings):
# This boot script loads the kernel and ramdisk from the
# SD card into memory, then runs them from there.
# --------------------------------------------------------
# Setup environment
setenv scriptid ***** Boot using ramdisk in memory *****
setenv console ttyS2,115200n8
setenv ramdisk /dev/ram0 rw
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} root=${ramdisk} 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} ramdisk.gz
bootm ${kerneladdr}
Hi Michael,
Thanks very much for your response. Just want to make sure that the
description from the above links will work on my board as my board is
Rev B.
Vamsi - You might also try changing the FAT32 partition to FAT16. That trick has worked on two different rev C boards I have used in the past, but I don’t know whether it will work for rev xM.
As you noted in a subsequent message, the FAT partition needs MLO and u-boot.bin in order to get to a u-boot prompt, and it requires uImage in order to boot the Linux kernel. The root filesystem can reside in a second ext2 or ext3 partition, or it can be a gzipped ramdisk file if you want to boot with ramdisk.
The validation image also contains boot scripts that set up the environment and boot using known-good boot arguments. When you are first learning how the board boots, I suggest doing this work by hand and making it work before attempting to create or change the script.
Yes. I have a Rev Ax/Bx board as well (didn't know that when I bought
it, but can tell from the u-boot messages). There is some question (to
me) whether the flash of the x-loader works properly. The serial
console output says the flashing worked but on reboot it appears I still
have x-loader 1.4.2. Not sure what version is on my SD card because the
version on the web site doesn't have the same version number - only a
"rev" ID. And I haven't gotten around to building a new x-loader from
source.
Anyway, other than that, the instructions work well for getting u-boot
and the kernel booted.
I'm currently trying to figure out why the kernel doesn't boot with a
ramdisk embedded in it. Must have done something wrong with my kernel
config as the rootfs seems to be okay based on:
http://landley.net/writing/rootfs-howto.html
and
http://landley.net/writing/rootfs-programming.html
Since I'm building a 2.6.32 kernel from git with SGX patches and the
validation image is a 2.6.28 kernel I had to dump the config
from /proc/config.gz and diff it (I use "meld" for that) to see what I
might have missed.
It's weird - I've put initramfs's in the kernel before and it just
worked. So I think I'm missing something simple and obvious - except to
me. 
Vamsi - You might also try changing the FAT32 partition to FAT16.
That trick has worked on two different rev C boards I have used in the
past, but I don't know whether it will work for rev xM.
The validation instructions don't mention the need for this but I found
that FAT32 worked fine if there was not a second partition with ext[2/3]
on it. If there is a second partition then FAT16 appears to be
required, possibly due to the size of the second partition. Both FAT16
and FAT32 seem to work fine to boot the validation images. This is true
for the Ax/Bx board I have, at least. Don't have a Cx or xM board.
As you noted in a subsequent message, the FAT partition needs MLO and
u-boot.bin in order to get to a u-boot prompt, and it requires uImage
in order to boot the Linux kernel. The root filesystem can reside in
a second ext2 or ext3 partition, or it can be a gzipped ramdisk file
if you want to boot with ramdisk.
It should be noted that once you create the partition and copy these
files in you can overwrite them later. At least everything but the MLO,
which I haven't tried to overwrite yet.
I'm a little confused by this "ordering" requirement however since MLO
is the x-loader and the x-loader boots from ROM (or NAND?), not the SD
card. I can see why the u-boot would need to be in a specific location
in NAND for x-loader to find it, but why on the SD card? The image file
is referenced by name in the fatload command. The only requirement
seems to stem from the format of the fatload command which appears to
specify which partition to look in for the named image file. And
therefore the location of the image file is configurable based on the
boot script.
The validation image also contains boot scripts that set up the
environment and boot using known-good boot arguments. When you are
first learning how the board boots, I suggest doing this work by hand
and making it work before attempting to create or change the script.
That's what I did too. I reproduced a script based on what I gleaned
from the bootargs from the kernel and examples of boot scripts in
Angstrom's distribution. Of course, reading
Documentation/kernel-parameters.txt in the kernel source tree helps in
understanding the kernel boot arguments too.
Hey guys,
guess what. I made some progress by testing the kernel that I built. it worked well. i did this by having the u-boot.bin loaded from the factory MMC card and just when its trying to load the uImage, i replace the card slot with my MMC card containing my uImage. it worked perfect.
However, the weird thing is i couldn’t get the board boot from my MMC card though i copied all the FAT contents of factory MMC to my MMC’s FAT partition. Any thoughts on that?
what could be possibly wrong?
Too hard to say since the factory card might have something different
than the validation images. It could be the method you used to copy the
files or the method you used to create the bootable partition on your
MMC card. If you use dd (on Linux) you could probably create an exact
copy of the factory card, but that would defeat the purpose of learning
how to create your own card with custom image files.
My board didn't even come with a factory card. Just the board. So I
had to download the images manually and create the SD card myself.
My suggestion is to follow the instructions for the validation images
for C4 and Bx boards:
http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation
The important part is how you create your root partition on the SD card
and (apparently) the order in which you copy files over. And of course
the files you copy should be retrieved from that page as well.
Information on formatting the SD card can be found either here:
http://processors.wiki.ti.com/index.php?title=MMC_Boot_Format
or here (for dual boot configurations with a FAT16 and an EXT2/3
partition):
http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat
Copy the files form the validation image collection to the SD card
exactly as it says on that page. While I might argue that not all files
are required, the goal is to get to a point of manually recreating a
bootable SD card with the validation images. Once you've done that you
begin to modify files on it to test your own builds.