When the PandaBoard boots it reserves 33554432 bytes (32MB) of RAM for VRAM. As these is no need for video this RAM can be better used by the builder so I went about removing the video drivers from the kernel.
I have successfully compiled a kernel that has no video drivers in it for the purpose of build machines. Thus I was able to reach over 900MB of RAM in the operating system along with the my previously built MLO and u-boot.bin files. How I disabled the drivers from the kernel is that I ran the command
make ARCH=arm CROSS_COMPILE=/path/to/cross/compiler menuconfig
In the menu I went to system type and under ARM System Type I selected TI OMAP. Under that option I went to TI OMAP2/3/4 Specific Features disabled TI OMAP2 and TI OMAP3 and then disabled OMAP 4430 SDP board from the list of the two remaining boards(Figure 1). I then went back to the main menu and went into the Deveice Driver subsection of the main menu. Went down to the Multimedia Support and deselected it. Then went into the graphics support sub menu, disabled all options except Backlight & LCD device support.(Figure 2)
Figure 1 Showing TI OMAP2/3/4/ Specific Features
Figure 2 Showing Graphics Support configuration.
I then exited the menuconfig and saved the config as the default. I then compiled the uImage for the kernel from the .config that got created from the menuconfig with the make command below.
make ARCH=arm CROSS_COMPILE=/path/to/cross/compiler uImage
The output from the free -m command that should 907MB available to Fedora is below. [root@cdot-panda-5-1 kernel]# free -m Unknown HZ value! (94) Assume 100. total used free shared buffers cached Mem: 907 15 892 0 0 3 -/+ buffers/cache: 11 895 Swap: 0 0 0
To avoid errors on boot about not finding modules I copied the /lib/modules/2.6.35-g6d019da-dirty to /lib/modules/188.8.131.52
To test the stablilty of my uImage with the 900MB of RAM I did a native compile of the kernel on the PandaBoard. I successfully got the compile without the board crashing that process took about 74 minutes. I am not sure if that is normal for native compiles but I am happy that my board did not seem to have stability issues