BeagleBone U-Boot Console Change

I’m trying to change the UBoot console port on my BeagleBone from ttyO0 to ttyO1 to declutter the USB interface. (Too much going on there with the serial content, mass storage, virtual ethernet, etc)

I’m utilizing TI’s recently released SDK version 5.04 to generate the targetfs, and a prebuilt UBoot image provided as part of the SDK.

I’ve made the following change to uEnv.txt, which has modified the ${console} env variable, but the console remains focused on ttyO0
console=ttyO1,115200n8

I have made changes to the pin Mux to ensure that the UART1TXD and UART1RXD lines are being utilized. I can echo content out that interface if I let the OS boot.

Any thoughts on what I might be missing? I’ve attached a printenv for reference.

Thanks,

Remo

printenv.txt (10.1 KB)

I'm trying to change the UBoot console port on my BeagleBone from ttyO0 to
ttyO1 to declutter the USB interface. (Too much going on there with the
serial content, mass storage, virtual ethernet, etc)

<snip>

I have made changes to the pin Mux to ensure that the UART1TXD and UART1RXD
lines are being utilized. I can echo content out that interface if I let
the OS boot.

Do you have the UART enabled in u-boot? Not just the console= line
and mux, but you need to have the clock on and tell u-boot to print
there, too. Last I knew, TI's u-boot repo did not even enable the
clocks for ttyO1.

See roughly my patch:
https://gist.github.com/2569638

It won't apply cleanly to TI's u-boot (I have a
include/configs/beaglebone.h that I made instead of the am335x_evm one),
but it should give you an idea of what needs to be changed for ttyO1
support.

-Andrew

Andrew,

I’ll have to do some more investigation into what is turned on in the precompiled u-boot from TI.
It sounds like I’ll need to go down the road of recompiling u-boot from source to include the necessary logic to get ttyO1 enabled.

Thanks,

Remo

I didn't realize you're using the precompiled u-boot from TI, sorry.

If the precompiled u-boot is built from the Arago u-boot repo, I don't
believe ttyO1 is enabled still (at least not in the Arago u-boot
master branch). There has been some action on the TI u-boot repo lately,
but none that I see fully enabling ttyO1. ttyO3 is enabled in Arago's
u-boot (it's used on the am335x_evm board) but not sure well that fits
your needs since it's not pinned out on the Bone headers.

You could probably write a script in your uEnv.txt to hit the registers
directly and enable ttyO1, but I think patching and compiling u-boot
might be faster and easier.

-Andrew

It will be my first round recompiling uboot from source. The link below seems like a good place to start, given my current development platform?

Link

Thanks,

Remo

That's probably as good as any other source if you're using all TI
provided stuff. The steps look correct (based on skimming it). Just make
sure to format your FAT partition and copy the MLO on first, before
u-boot.

If you want to use someone else's cross compilers, just make sure to
put the right value for CROSS_COMPILE= in and you'll be all set.

-Andrew

Andrew,

I’m not exactly married to the TI SDK at this point. I did use the YoctoProject / bitbake to create an functional image a few weeks back. That method is somewhat attractive, since it boasts the ability to build the package manager to be deployed on a central server. That would certainly ease production woes down the road.

Do you have build preferences that you see being particularly beneficial?

Thanks,
Remo

Any ARM cross compiler should do the trick. I'm partial to the
Emdebian toolchain [1]. I should mention that I do get picked on in
IRC for using it, though :slight_smile: It's not the most modern toolchain (GCC
4.4 based), but I like it.

[1]: http://wiki.debian.org/EmdebianToolchain

If you have a working toolchain for cross compiling, just use that. No
need for finding something different. Regarding u-boot sources, right
now you pretty much are stuck with TI, either from their SDK or from
Arago. Pretty soon (maybe already?) TI will get their code into mainline
u-boot, when that happens, use mainline.

-Andrew

Andrew, Do you have a working u-boot image (or source tree) that boots uses UART1 that you would like to share? You would be my hero.

Sorry, I guess I meant to address that to Remo.

在 2012年5月11日星期五UTC+8下午10时22分03秒,Remo写道:

Naxing Electronics has a Beaglebone companion board(NBD02) expands UART1 which can be used as console.
http://www.nxelec.com/products/development-kit/beaglebone-companion

You can logon their forum and find a binary uboot image fits your needs.
http://www.esky-sh.com/bbs/viewforum.php?f=20

在 2012年8月23日星期四UTC+8上午7时39分56秒,Dave H.写道:

Sorry for my slow reply, I missed this on the list.

I've published a git branch[1] based off the most recent TI release
(v2011.09_AM335xPSP_04.06.00.08). Tested on an A3 Bone with Debian gcc
4.4 cross compilers from Emdebian[2].

[1]: https://github.com/bradfa/u-boot/tree/am33x_uart1
[2]: http://wiki.debian.org/EmdebianToolchain

See if that works for you. I just did a quick test[3] on an A3 using a
SparkFun adapter[4].

[3]: https://gist.github.com/3552559
[4]: https://www.sparkfun.com/products/449

-Andrew

Quick update for those who care, but since mainline u-boot now boots the
Beaglebone, I've pushed commits on top of that to enable UART1 as the
default serial output [1].

[1]: https://github.com/bradfa/u-boot/tree/beaglebone-uart1

This is on top of the current state of the mainline u-boot tree as of
this morning, so not at any kind of tag or clean rc release but things
seem to work pretty well in my quick testing. Again, tested on an A3
bone with SparkFun adapter.

-Andrew

Cool. If you want to get this into mainline my suggestion would be to update am335x_evm.h to use CONFIG_SERIAL_MULTI (so that both UARTs can be available), set CONFIG_ENV_OVERWRITE so that stdin/stdout/stderr can be changed in the environment and then add to boards.cfg a target that will build with stdin/out/er using serial1 instead of the defaults. Roughly and off the top of my head of course. Thanks!

OK, I'll try to implement your suggestion and send a patch to the u-boot
list. Thanks for the pointers!

My one concern would be that not everyone wants to enable UART1's pin-
mux due to possible conflicts with other cape I/O. As I configure in my
changes today, regardless of which UART you output to, I believe UART1's
pin-mux gets setup. Possibly your suggestions above can prevent that
and thus make my concern unwarranted, but it's not clear to me (yet).
I'll look into this but any further nudges in the right direction would
be welcomed.

-Andrew

Awesome! Thanks!

Mainline u-boot (as of 2013.01-rc1) now boots BeagleBone or
am335x_evm with UARTs 0,1,2,3,4, or 5. Use the
'am335x_evm_uartX_config' (replace X with 1,2,3,4, or 5) to use a uart
other than 0. Just use the 'am335x_evm_config' if you want uart0.

-Andrew

hi,
HOw to change console path of ttyO2(uart3) to ttyUSB0 in U-Boot(make menuconfig?