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.
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:
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.
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.
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.
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.
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?
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 It's not the most modern toolchain (GCC
4.4 based), but I like it.
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.
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].
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].
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.
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.
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.
It's not the most modern toolchain (GCC