U-boot.bin UART2 expansion header

[Hurdy]

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

[Dirk Behme]

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

[StatelyAlbion]

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

[Søren Steen Christensen]

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... :-)

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) :-)

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... :-)

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

[StatelyAlbion]

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.

[StatelyAlbion]

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?

[StatelyAlbion]

>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)

[Hunyue Yau]

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.

--
Hunyue Yau
http://www.hy-research.com/

[Søren Steen Christensen]

> 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 :-( 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" :-)

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 :-)

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...
:-)

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

[Steve Sakoman]

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

[Dirk Behme]

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 ;)

Best regards

Dirk

[StatelyAlbion]

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.

[StatelyAlbion]

> 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

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?

[Dirk Behme]

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

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

[StatelyAlbion]

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.

[StatelyAlbion]

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.

[Steve Sakoman]

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

[StatelyAlbion]

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?

[StatelyAlbion]

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.

[Søren Steen Christensen]

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

[StatelyAlbion]

Hi everyone,

I had a some issues with my board. I accidentally erased all of my
NAND memory so I had to recover my board.

Anyway, getting back to the UART issue, I now have my board X-loader
up to 1.4.2 and it now boots U-boot from my SD card.

I am using Koens angstrom March release.

I compile my u-boot with the beagle.h provided from Sakoman @

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

But when I boot my board, it recognises the new U-boot but says failed
to load kernal image. If I used the latest u-boot from the angstrom
site it boots fine. But this doesn't have UART2 mux setup.

Any ideas how I can solve this?

Kind regards,

rob

[Dirk Behme]

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

> Can someone help me again please! Sorry everyone for my troubles. I've
> been trying to load a new U-boot.
>
> I built a new U-boot and from an eLinux page I did the following:
>
> mmcinit
> fatload mmc 0 0x80200000 u-boot.bin
> nand unlock
> nand ecc sw
> nandecc sw
> nand erase 80000 160000
> nand write.i 0x80200000 80000 160000
> reset
>
> I reset the board and halted the boot. Typed 'version' and I got,
> U-Boot 2009.03-00333-g7ee38c0-dirty (Apr 17 2009 - 19:58:35)
>
> When it tried to load Angstrom I get the error
>
> ** Unable to use mmc 0:1 for fatload
> **
> Wrong Image Format for bootm
> command
> ERROR: can't get kernel image!
>
> Does anyone know how to fix this?

In recent U-Boot mmcinit command changed. 'mmcinit' is replaced by
'mmc init' (with additional device parameter which seems we don't need
here).

I.e. try to replace 'mmcinit' by 'mmc init'.

With this I get

-- cut --
...
mmc1 is available
reading uImage

2502044 bytes read
...
-- cut --

Best regards

Dirk

[StatelyAlbion]

> In recent U-Boot mmcinit command changed. 'mmcinit' is replaced by
> 'mmc init' (with additional device parameter which seems we don't need
> here).
>
> I.e. try to replace 'mmcinit' by 'mmc init'.

Hi Dirk, I've found a patch you attached to another post called
'mmc_init_fix.txt'.

I applied the patch to my u-boot-main:

patch -p1 < patches/mmc_init_fix.txt

The patch ran fine with no problem.
I checked the u-boot-main/include/configs/omap3_beagle.h file and the
lines have been changed to:

#define CONFIG_BOOTCOMMAND \
"if mmc init; then " \
"if run loadbootscript; then " \
"run bootscript; " \
"else " \

I built a new u-boot.bin but I get the same error message;

Texas Instruments X-Loader 1.4.2 (Jan 30 2009 - 19:16:17)
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2009.03-00333-g7ee38c0-dirty (Apr 18 2009 - 15:30:40)

OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
In: serial
Out:
serial
Err:
serial
Board revision Ax/
Bx
Die ID
#7a8400020000000004013ef102020011
Hit any key to stop autoboot:
0
Unknown command 'mmcinit' - try
'help'

** Unable to use mmc 0:1 for fatload
**
Wrong Image Format for bootm
command
ERROR: can't get kernel image!

Any ideas?

Thank you, Rob

[Dirk Behme]

What does

printenv

gives you?

Dirk

Btw.: You might like to join #beagle for questions like this.

[StatelyAlbion]

> What does printenv gives you?

OMAP3 beagleboard.org # printenv
bootdelay=10
baudrate=115200
loadaddr=0x82000000
console=ttyS2,115200n8
videomode=1024x768@60,vxres=1024,vyres=768
videospec=omapfb:vram:2M,vram:4M
mmcargs=setenv bootargs console=${console} video=${videospec},mode:$
{videomode} root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwat
nandargs=setenv bootargs console=${console} video=${videospec},mode:$
{videomode} root=/dev/mtdblock4 rw rootfstype=jffs2
loadbootscript=fatload mmc 0 ${loadaddr} boot.scr
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
nandboot=echo Booting from nand ...; run nandargs; nand read $
{loadaddr} 280000 400000; bootm ${loadaddr}
dieid#=7a8400020000000004013ef102020011
filesize=0
bootargs=console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait
bootcmd=mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000
stdin=serial
stdout=serial
stderr=serial

Environment size: 956/131068 bytes

ah I see it says bootcmd = mmcinit rahter than mmc init.

[StatelyAlbion]

> ah I see it says bootcmd = mmcinit rahter than mmc init.

One question about when I reset this.
The beginner guide says:

# setenv bootcmd 'mmcinit;fatload mmc 0 80300000 uImage;bootm
80300000'

but my console shows:

bootcmd=mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000

Do I set; fatload mmc 0:1 0x80200000 uImage or fatload mmc 0 80300000
uImage?

[StatelyAlbion]

> bootcmd=mmcinit; fatload mmc 0:1 0x80200000 uImage; bootm 0x80200000

this is the one.

Thank you, it boots now :). I appreciate your assistance.

Rob

[StatelyAlbion]

Hi Everyone,

I just wanted to thank you all for your help so that I can better
understand and get the UART2 working.
It all works perfectly now thank you!

When college is over in the summer, exams are soon so I'm really busy
at the moment, I will try to write up a 'newbie guide' on how to get
UART2 up and running for those tailing behind me.

Thank you again everyone,

Rob