U-boot.bin UART2 expansion header

Hi everyone, thank you for your time to read this.

I am a real newbie to this OS develpment and I apologize if my
questions may seem a little silly or lack technicalities.

I am wondering if anyone has a u-boot.bin file they can share with me
that has the UART2 setup on the pin mux so I can load it onto my SD
card boot partition?

I don't really like to ask but I'm having difficulty configuring it
myself. I'm at a loss as to whether I have configured U-boot
incorrectly or if it is my C test code that is not reading/writing the
UART registers correctly.

Below is what I did to setup u-boot myself:

I managed to download a copy of the u-boot files called u-boot-main.

I located the file beagle.h found at '../u-boot-main/board/omap3/
beagle/
beagle.h'.

My aim is to get the UART2 header pins configured on the mux. So I did
following;

I edited the lines of code with the heading Bluetooth in '../
beagle.h'.

My new file now has the following lines:

MUX_VAL(CP(MMC2_DAT6), (IEN | PTU | EN | M4)) /*GPIO_138*/\
MUX_VAL(CP(MMC2_DAT7), (IEN | PTU | EN | M4)) /*GPIO_139*/\
/*Bluetooth*/\
MUX_VAL(CP(MCBSP3_DX), (IEN | PTU | EN | M1)) /*UART2_CTS*/
\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\
MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_RTS*/\
MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART2_RX*/\
MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M4)) /*GPIO_144*/
\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M4)) /*GPIO_145*/
\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M4)) /
*GPIO_146*/\
MUX_VAL(CP(UART2_RX), (IDIS | PTD | DIS | M4)) /
*GPIO_147*/\
/*Modem Interface */\
MUX_VAL(CP(UART1_TX), (IDIS | PTD | DIS | M0)) /*UART1_TX*/
\
MUX_VAL(CP(UART1_RTS), (IDIS | PTD | DIS | M4)) /*GPIO_149*/
\

I then rebuilt u-boot-main to give me u-boot.bin.
I achieved this by using the following commands:

#make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
#make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
#make CROSS_COMPILE=arm-none-linux-gnueabi-

would you say this is correct to enable UART2 on the header expansion
pins?

I have tested with some C code to see if I can send and recieve data
on the UART but with no luck. I am unsure if there is a problem with
my C code or that u-boot.bin isn't working properly.
Is there a method to test that the UART2 pins are setup correctly with
the mux or than writing my own test code?

I would upload a copy of my C code if anyone is interested at looking
at it, but, I am unsure how to attach files to a post on this google
groups.

Thank you for your time,

Any assistance is greatly appreciated.

Rob

Hi Rob,

all steps you give below how to edit and build U-Boot look fine.

For the detailed pin mux, we need to know about which Beagle board
revision we talk (rev Bx or rev C). There are differences in UART2
expansion header pin mux between these two Beagle revisions.

If nobody else is faster, I could look at the pin mux details at the
weekend.

For testing, the easiest way would be to check with a scope.

Best regards

Dirk

Hurdy wrote:

Hi Dirk,

Many thanks for your response. You are right to question my board
revision :). I've only just realised today that the example UART2 pin
mux code I have been using is for revision C and I have revision B5!!
Silly me :).

So, I've been studing the UART2 pin mux code for the Rev C board to
try and work out how I need to do it for my revision (B5). I'm really
confused with this.

For Example;

MUX_VAL(CP(MCBSP3_DX), (IEN | PTU | EN | M1)) /*UART2_CTS*/\

To me, this looks like it is saying make McBSP3_DX, Enable Input, Pull
High, Enable?, Mux 1.

then later it says;

MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M4)) /*GPIO_144*/\

I don't understand how this sets up the pin to be UART2_CTS. Does M1
refer to as Mux 1? The ../beagle.h file just calls it mode and doesn't
really say much else. To me, as a newbie, it suggest Mux1 (at a
guess).

another example;

MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M4)) /*GPIO_146*/\

To me, this says, make UART2_TX, Disable as Input, Pull Low, Disable?,
Mux 4.

I don't understand how UART2_TX is used to enable GPIO_146.

From looking at the beagleboard System Reference Manual and reading
table 20 'Expansion Connector Signals' I can see the pin link between
UART2_TX and GPIO_146. I don't understand what the lines of code do to
enable it as UART2_TX.

I'm just trying to see if I can work out how it works, but it's quite
confusing, To me anyway :0).

Thank you for your time,

Any assistance on how to set this up for Rev B5 would be greatly
appreciated.

Thanks again,

rob

Many thanks for your response. You are right to question my board
revision :). I've only just realised today that the example UART2 pin
mux code I have been using is for revision C and I have revision B5!!
Silly me :).

So, I've been studing the UART2 pin mux code for the Rev C board to
try and work out how I need to do it for my revision (B5). I'm really
confused with this.

For Example;

MUX_VAL(CP(MCBSP3_DX), (IEN | PTU | EN | M1)) /*UART2_CTS*/\

To me, this looks like it is saying make McBSP3_DX, Enable Input, Pull
High, Enable?, Mux 1.

then later it says;

MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M4)) /*GPIO_144*/\

I don't understand how this sets up the pin to be UART2_CTS. Does M1
refer to as Mux 1? The ../beagle.h file just calls it mode and doesn't
really say much else. To me, as a newbie, it suggest Mux1 (at a
guess).

another example;

MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M4)) /*GPIO_146*/\

To me, this says, make UART2_TX, Disable as Input, Pull Low, Disable?,
Mux 4.

I don't understand how UART2_TX is used to enable GPIO_146.

From looking at the beagleboard System Reference Manual and reading
table 20 'Expansion Connector Signals' I can see the pin link between
UART2_TX and GPIO_146. I don't understand what the lines of code do to
enable it as UART2_TX.

I'm just trying to see if I can work out how it works, but it's quite
confusing, To me anyway :0).

Thank you for your time,

Any assistance on how to set this up for Rev B5 would be greatly
appreciated.

Thanks again,

Hi Rob,

Allow me to answer this. Most the balls on the OMAP can be configured for
one of several different signals - This is the Mux mode, which is a number
from 0-7 - causing one of 7 internal signals to reach the ball on the
package. Furthermore most balls have an internal pull up/down, which can be
en- or disabled as wanted... The comment copied below tells the meaning of
the different constants in U-Boot...

/*
* IEN - Input Enable
* IDIS - Input Disable
* PTD - Pull type Down
* PTU - Pull type Up
* DIS - Pull type selection is inactive
* EN - Pull type selection is active
* M0 - Mode 0
*/

The main constants, which might cause confusion are the DIS and EN, which
only decides if the PULL is active or not - It has nothing to do with
indicating if the pin as such is enabled or disabled. Pins are always
enabled, and can't be disabled. The IP blocks internal can however be
disabled causing output-pins to be not controlled unless the pull (up or
down) is active, but this is another advanced topic left for next time - Or
the ones aiming at reading the complete TRM chapter 7 in details... :slight_smile:

Information about mux mode correlation to IP block (function) can be found
in table 7.4 in the TRM. A look in the Data Manual is however very helpful
as well, since this gives the correlation to the actual ball names (i.e.
AB25 or K9) :slight_smile:

Your confusion with respect to UART2_TX and GPIO 146 is answered by the
fact, that GPIO 146 is activated on the ball called UART2_TX in case it's
muxed to mode 4 - Look at page 819 in the TRM... :slight_smile:

I hope this answers your questions? In case not please don't hesitate to ask
again and I will try to answer best possible...

Best regards
  Søren

Thank you for your response Soren. I appreciate it very much.

I found the TRM table on page 819.
It shows that: UART2_CTS = Mode 0
                      UART2_RTS = Mode 0
                      UART_TX = Mode 0
                      UART_RX = Mode 0

                      MCBSP3_DX = Mode 1
                      MCBSP3_DR = Mode 1
                      MCBSP3_CLKX = Mode 1
                      MCBSP3_FSK = Mode 1

                      GPIO_144 = Mode 4
                      GPIO_145 = Mode 4
                      GPIO_146 = Mode 4
                      GPIO_147 = Mode 4

Reading the BB Reference Manaul Revision C2.2 table 20 p.96 I see
that:

                      UART2_CTS = MUX 0
                      UART2_RTS = MUX 0
                      UART_TX = MUX 0
                      UART_RX = MUX 1

                      MCBSP3_DX = MUX 1
                      MCBSP3_DR = MUX 1
                      MCBSP3_CLKX = MUX 1
                      MCBSP3_FSK = Mode 0

                      GPIO_144 = MUX 4
                      GPIO_145 = MUX 4
                      GPIO_146 = MUX 4
                      GPIO_147 = Doesn't Exist
                      GPIO_143 = MUX 4 = UART2_RX & MCBSP_DR

The document does state, 'For the Rev c2, the signals in shaded areas
replace the signals on the line above it'. So this tell me the signals
on the line above represents how they used to be in previous
Revisions?
So, to me that say that for my Rev B5 board my MUX is:

                      UART2_CTS = MUX 1
                      UART2_RTS = MUX 1
                      UART_TX = MUX 1
                      UART_RX = MUX 1

                      MCBSP3_DX = MUX 0 & MUX 2
                      MCBSP3_DR = MUX 0 & MUX 2
                      MCBSP3_CLKX = MUX 0 & MUX2
                      MCBSP3_FSK = MUX 0 & MUX2

                      GPIO_144 = Doesn't Exist (only for RevC)
                      GPIO_145 = Doesn't Exist (only for RevC)
                      GPIO_146 = Doesn't Exist (only for RevC)
                      GPIO_147 = Doesn't Exist (only for RevC)

but; GPIO_140 = MUX 4 = MCBSP3_DX & UART2_CTS
               GPIO_141 = MUX 4 = MCBSP3_DR & UART2_RTS
               GPIO_142 = MUX 4 = MCBSP3_CLKX & UART2_TX
               GPIO_143 = MUX 4 = MCBSP3_FSX & UART2_RX

But, I have a revision B5 board.
So, reading BB ref man B7.2 table 21 p.96 I see:

                      UART2_CTS = Option C
                      UART2_RTS = Option C
                      UART_TX = Option C
                      UART_RX = Option C

                      MCBSP3_DX = Option A
                      MCBSP3_DR = Option A
                      MCBSP3_CLKX = Option A
                      MCBSP3_FSK = Option A

                      GPIO_144 = Doesn't Exist
                      GPIO_145 = Doesn't Exist
                      GPIO_146 = Doesn't Exist
                      GPIO_147 = Doesn't Exist
but;
                     GPIO_140 = Option B = UART2_CTS & MCBSP3_DX
                     GPIO_141 = Option B = UART2_RTS & MCBSP3_DR
                     GPIO_142 = Option B = UART2_TX & MCSP3_CLKX
                     GPIO_143 = Option B = UART2_RX & MCBSP3_FSX

I'm assuming Option means Mux? So, A=MUX0, B=MUX1, C=MUX2, D=MUX4?

I am really confused what documents I should be taking note of and
what ones are incorrect for my B5 board.
They each tell me different things.

Ah.. I think I've just had a brain wave! :0).

I re-downloaded a fresh u-boot-main.

Under Bluetooth heading in ../beagle.h, lets look at:
MUX_VAL(CP(MCBSP3_DX), (IDIS | PTD | DIS | M4)) /*GPIO_140*/\

Does the 'CP(MCBSP3_DX)' refer to CONTROL_PADCONF_MCBSP3? as is shown
in the TI Technical Ref Manual table 7-4 p.819.

and therefore;

MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0)) /*UART2_CTS*/\

refers to the CONTROL_PADCONF_UART2_CTS?

What I'm getting at, is that the CF name means CONTROL_PADCONF?

What I don't understand is why UART and MCBSP3 show up in several
places. As mentioned in the previous message I have several documents
that tell me different things about the MUXing. I don't understand how
I would configure them so that I get UART2 on the header of my Rev B5
board.

The U-boot main I have shows:

/*Bluetooth*/\
MUX_VAL(CP(MCBSP3_DX), (IDIS | PTD | DIS | M4)) /*GPIO_140*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M4)) /*GPIO_142*/\
MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(MCBSP3_FSX), (IDIS | PTD | DIS | M4)) /*GPIO_143*/
\
MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0)) /*UART2_CTS*/\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M0)) /*UART2_RTS*/\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0)) /*UART2_TX*/\
MUX_VAL(CP(UART2_RX), (IDIS | PTD | DIS | M4)) /*GPIO_147*/\
/*Modem Interface */\

I don't really understand why MCBSP3 is there and what I'm supposed to
do with it. Surely I just enable UART_RX as IEN (Enable Input), TX is
an output so IDIS is correct?

What I'm getting at, is that the CF name means CONTROL_PADCONF?

That said, there is only:
CONTROL_PADCONF_MCBSP3_DX[15:0]
CONTROL_PADCONF_MCBSP3_DX[31:16]
CONTROL_PADCONF_MCBSP3_CLKX[15:0]
CONTROL_PADCONF_MCBSP3_CLKX[31:16]

there no DR or FSX. I'm very confused now! Lol :0)

Hi,

I don't have the docs in front of me right now, but prehaps keeping
this in mind will help -

The registers as described by the TRM are 32bit registers. But functional
wise, the lower 16bit and the upper 16bit refer to different physical
balls. Note the '[15:0]' and '[31:16]' in what you quoted. The naming
convention used appears to be function 0 of that ball so most likely
either the [15:0] or the [31:16] part has a different name (based on
function/mode 0) that is used in Linux and U-boot.

The U-boot main I have shows:

/*Bluetooth*/\
MUX_VAL(CP(MCBSP3_DX), (IDIS | PTD | DIS | M4))
/*GPIO_140*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M4))
/*GPIO_142*/\
MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(MCBSP3_FSX), (IDIS | PTD | DIS | M4))
/*GPIO_143*/
\
MUX_VAL(CP(UART2_CTS), (IEN | PTU | EN | M0))
/*UART2_CTS*/\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M0))
/*UART2_RTS*/\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M0))
/*UART2_TX*/\
MUX_VAL(CP(UART2_RX), (IDIS | PTD | DIS | M4))
/*GPIO_147*/\
/*Modem Interface */\

I don't really understand why MCBSP3 is there and what I'm supposed to
do with it. Surely I just enable UART_RX as IEN (Enable Input), TX is
an output so IDIS is correct?

Hmm - Apparently TI could improve on the description of the PADCONF and the
pin muxing since it's causing may persons trouble :frowning: Having worked with it
for 6+ years, it's however kind of trivial - Therefore please forgive me in
case I make any assumptions only for "internals" :slight_smile:

You are right, that the CP(xxx) refers to an actual ball (one of the PADCONF
registers) - Or to be completely correct ½ of a PADCONF register, since they
are 32-bit and thereby manages two balls using the upper and lower 16-bits
of the register as just described by Hunyue Yau.

The UART and McBSP signals can me muxed to one of several balls - (even to
multiple balls at the same time, although it's usually not a good idea, but
for some output pins it might sometimes be an advantage :slight_smile:

The change from Rev B to Rev C boards is the change from balls AF6, AE6 and
AF5 to balls AB26, AB25 and AA25...

In the code above, the four balls associated with the MCBSP3_ *PADCONF are
configured to GPIOs (mode 4), while the balls associated with the UART2_*
PADCONF are configured for their main function UART2 = Mode0.

You cannot OR/AND the modes as in our previous post - only select function
per pin at a time, but I guess you already learned this recognized this...
:slight_smile:

Best regards - I hope this helps - Don't hesitate to ask - Good luck
  Søren

I mentioned this in another similar thread, but will repeat it here.

The omap3-dev banch of u-boot already has code to deal with the rev
B/C differences in pinmux:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=board/omap3/beagle/beagle.h;h=0a3c9a551ca5d810df0132d2d813b01ea8266dd5;hb=refs/heads/omap3-dev

Info to clone this u-boot repo:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=summary

Be sure to use the omap3-dev branch.

Pre-built binaries can be found here:

http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/

If you find any issues please post bug reports/patches on this list
and Dirk and I will work to integrate them and push them upstream.

Steve

Steve Sakoman wrote:

I mentioned this in another similar thread, but will repeat it here.

The omap3-dev banch of u-boot already has code to deal with the rev
B/C differences in pinmux:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=blob;f=board/omap3/beagle/beagle.h;h=0a3c9a551ca5d810df0132d2d813b01ea8266dd5;hb=refs/heads/omap3-dev

Info to clone this u-boot repo:

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=summary

Be sure to use the omap3-dev branch.

Pre-built binaries can be found here:

http://www.sakoman.com/feeds/omap3/glibc/images/beagleboard/

If you find any issues please post bug reports/patches on this list
and Dirk and I will work to integrate them and push them upstream.

Yes, as Steve mentions, omap3-dev branch already deals with UART2 pin mux differences.

Alternatively, if you like to use U-Boot mainline, you could try to grab

http://lists.denx.de/pipermail/u-boot/2009-April/051013.html

and apply it manually to mainline.

I was confused a little by this pin mux stuff, too. Hopefully we have it correct now :wink:

Best regards

Dirk

Thank you everyone for your input.

Let me now see if I have everything correct now.

Beagleboard Rev B Ref Man, figure 43, P.82 shows that the expansion
header is;

     Label Ball Pin
McBSP3_DX AF6 2
McBSP3_CLKX AF5 4
McBSP3_FSX AE5 6
McBSP3_DR AE6 8

So, I want UART2 on these pins.

Therefore I need to make McBSP3 = UART2. Correct?

So, the TI OMAP35x Technical Ref Man says;

CONTROL_PADCONF_MCBSP3_DX[15:0] = UART2_CTS @ Mode 1
CONTROL_PADCONF_MCBSP3_DX[31:16] = UART2_RTS @ Mode 1
CONTROL_PADCONF_MCBSP3_CLKX[15:0] = UART2_TX @ Mode 1
CONTROL_PADCONF_MCBSP3_CLKX[31:16] = UART2_RX @ Mode 1

So in the MUX I need to set CP(MCBSP3) to Mode 1 to get UART2 on it.

But, there are 2 ways UART2 can be MUXed. So I need to in the MUX '../
beagle.h' set UART2 to say GPIO.
GPIOs are found in Mode 4 according to the TI OMAP35x Ref Man.

So this brings me to believe that I need to set my MUX file to this:

/*Bluetooth*/\
MUX_VAL(CP(MCBSP3_DX), (IEN | PTU | EN | M1)) /*UART_CTS*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M1)) /*UART_TX*/\
MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART_RTS*/\
MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART_RX*/\
MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M4)) /*GPIO_*/\
MUX_VAL(CP(UART2_RTS), (IDIS | PTD | DIS | M4)) /*GPIO_*/\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M4)) /*GPIO_*/\
MUX_VAL(CP(UART2_RX), (IDIS | PTD | DIS | M4)) /*GPIO_*/\

But, this is exactly the same as I had from the example I was given
for a Rev C board.
Anyway, I built this as a new u-boot.bin file and ran some code to
test it on a scope but with no luck.

Is there anyway flaws in my work anyone can point out?

Thank you, Rob.

Alternatively, if you like to use U-Boot mainline, you could try to grab

[U-Boot] [PATCH v3] OMAP3: Beagle: Set pinmux conditionally for Rev C boards

Hi Dirk. So are you saying that from the link you gave me if I apply
the changes manually (shown with +) to the U-boot-main that I have and
rebuild it, the pin mux will be ready to work with a RevB board?

StatelyAlbion wrote:

Alternatively, if you like to use U-Boot mainline, you could try to grab

[U-Boot] [PATCH v3] OMAP3: Beagle: Set pinmux conditionally for Rev C boards

Hi Dirk. So are you saying that from the link you gave me if I apply
the changes manually (shown with +) to the U-boot-main that I have and
rebuild it, the pin mux will be ready to work with a RevB board?

Yes, at least we hope so. See Steve's comment about 'report problems' :wink:

Best regards

Dirk

Btw.: You don't have to make the changes in that patch marked with '+' manually. You can use the tool 'patch' to apply it to mainline. See e.g.

http://wiki.davincidsp.com/index.php?title=Working_with_Linux_patches#Applying_a_patch

While this is Kernel specific, it will work similar with all patches. E.g. save above patch in a file, and then do

patch -p1 < file_which_contains_the_patch

Ok I added these lines of code to my beagle.h code.

/*Bluetooth*/\
MUX_VAL(CP(MCBSP3_DX), (IEN | PTD | DIS | M1)) /*UART2_CTS*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M1)) /*UART2_RTS*/\
MUX_VAL(CP(MCBSP3_CLKX), (IDIS | PTD | DIS | M1)) /*UART2_TX*/\
MUX_VAL(CP(MCBSP3_FSX), (IEN | PTD | DIS | M1)) /*UART2_RX*/\
MUX_VAL(CP(UART2_CTS), (IEN | PTD | DIS | M4)) /*GPIO_144*/\
MUX_VAL(CP(UART2_RTS), (IEN | PTD | DIS | M4)) /*GPIO_145*/\
MUX_VAL(CP(UART2_TX), (IEN | PTD | DIS | M4)) /*GPIO_146*/\
MUX_VAL(CP(UART2_RX), (IEN | PTD | DIS | M4)) /*GPIO_147*/\

I have my Tx line attached to a scope, but it is just HIGH constantly
when I try to run my demo code.
Can you confirm that this should work for a RevB board?
If it should then maybe there is a problem with my C code writing to
the Tx.

Ok, I've used this ../beagle.h file as my MUX setup, which is supposed
to have UART2 setup on the expansion header for Rev B5. Correct?

So I built the u-boot.bin file with the following commands,

cd u-boot-main
make CROSS_COMPILE=arm-none-linux-gnueabi- mrproper
make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_beagle_config
make CROSS_COMPILE=arm-none-linux-gnueabi-

Loaded this onto my boot partition, logged into angstrom and ran my
test program that constantly loops to put ASCII 'R' onto the Tx line.
My scope just shows it is constantly HIGH @ 1.8V.

If you don't trust your program, then just do something from the
command line like:

cp /dev/random /dev/ttyS1

If you don't trust your build process, the use the pre-built u-boot.

Steve

Hmm.. I just tried booting up my board with no u-boot file on my SD
card and it booted fine.

Does this mean my board is booting from NAND and no actually reading
my U-boot file on my SD card boot partition?

Yes that's it! How silly am I! I didn't occur to me that u-boot was
booting from the original one flashed in when I bought the board.
Newbies for you huh!

I halted the boot, and typed 'version'. July 2008! haha jokes!

Well I now have to figure out how to make it use the u-boot on my SD
card.

Yes that's it! How silly am I! I didn't occur to me that u-boot was
booting from the original one flashed in when I bought the board.
Newbies for you huh!

I halted the boot, and typed 'version'. July 2008! haha jokes!

Well I now have to figure out how to make it use the u-boot on my SD
card.

Update the x-loader in the NAND to the newest version from GIT (1.4.2 - or
something like this I think to remember). This will use the U-boot on MMC
preferred to the U-boot in NAND... In case of no MMC or no U-boot on MMC it
will try to load U-boot from NAND...

You can update the x-loader by following the BeagleBoard recovery
procedure...

Best regards
  Søren