I've seen it done, by just using the kernel pin mux options in
userspace, but searching this group hasn't turned it up yet. (i know
it's out there..)
So, what are you suggesting I do then?
There's a good example for the BeagleBone here:
http://www.gigamegablog.com/2012/01/22/beaglebone-coding-101-using-the-serial-and-analog-pins/
under "Serial I/O"..
Even thou it's for the BeagleBone, the same pin mux procedure will
work for the BeagleBoard, (it's the same kernel driver) you'll just
need to reference the Beagle SRM for the actual pin name/locations on
the xM...
http://beagleboard.org/static/BBxMSRM_latest.pdf
The latest stable is "v3.2.19-x13" with lots of expansion board fixes
(zippy/wifi/lcd/etc..)
To Install on beagle:
wget http://rcn-ee.net/deb/wheezy-armhf/v3.2.19-x13/install-me.sh
/bin/bash install-me.sh
(reboot)
So I run the install-me.sh and I get 3.2.19 installed? I can deal with
that.
Correct..
Check the /boot/uboot/uEnv.txt
If it references uImage, then it's pre zImage transition..
(Background, on my last demo image upload, Debian armhf's apt was
broken, so it didn't get updated when the Ubuntu demo images got their
first "zImage" release.. The Debian armhf image planned for the next
few days will have that new method)
The /boot/uboot/uEnv.txt or the one located in the FAT16 partition?
That's the same one.. in my demo images, /etc/fstab is setup to have
the boot fat16 partition mount by default as "/boot/uboot"
Also,
since it did reference uImage, what does that mean for me? Will running
that script fix everything?
That install-me.sh script will search /boot/uboot to see if you have a
uImage and if so, will then regenerate another uImage to replace it
for compatibility sake.. (if it detects a zImage, it won't create a
uImage file..)
I personally would really like to re-write that whole file but I can't find
a straight-forward reference to explain every option and how it should be
used.
Yeah, there really isn't a good reference... Basically it's a file of
a bunch of variables (with lots of BeagleBoard specific kernel
display/expansion/speed options.).. It's loaded early in u-boot's
runtime, replacing a lot of default u-boot variables, (some variables
are even unchanged..).. After they are loaded u-boot calls "run
loaduimage" at that point my custom uEnv.txt has full control of the
u-boot boot process..
Sorry, I don't mean to pester you with what may be stupid questions but
messing with the kernel is what I have the least experience in with linux
and I find the way that this is set up to be a little more confusing
compared to x86 setups. I run Debian and Arch on my computers as my main
OSes so even just the u-boot thing seems very foreign to me.
Your not the first either, u-boot is very foreign to a lot of people..
It tries to do a lot of generic things on systems with very limited
memory/resources/io...
On a regular desktop pc, if there is a problem after a kernel update,
most of the time there's a user that initiated or someone around that
can fix it.. With embedded devices, sometimes they are installed
somewhere where's it's really hard to 'fix', but yet has internet
access and the user wants to safely (within reason) upgrade the system
packages... Since i do full rolling releases, it's kinda hard to
guarantee someone who installed debian squeeze with v2.6.32.x can be
safely and easily upgraded to v3.2.x with no regressions.. So by
making it slightly manual, i'm assuming the user knows the risks and
takes care in the update.. (the script will also backup the boot
files)... At the same time, going from 3.2.16 -> 3.2.18 could be
automatic as the patchset is pretty mininal..
Ok makes sense. I don't intend to keep the kernel (or all software in
general) fully up to date anyway, hence me using wheezy instead of sid. I'm
just aware of all the amazing performance improvements made on ARM for linux
lately and I would really like to take advantage of them. Once I do, I
don't really care about getting the latest.
The separate FAT16 'boot' partition, is what the omap bootrom and
u-boot reads.. Take a look at uEnv.txt, you can kinda see how and
what files are loaded/used..
Right, I knew that. But what I don't get is why there's also a /boot/
folder in the 2nd partition which seems to have many similar files as the
FAT16 partition, and what really seems to confuse me is the FAT16 partition
seems to have very little association with the 2nd. I haven't really found
any references that explicitly explain why and/or how this armhf setup
works, so this is why I find it all so confusing.
Actually, there's 2 answers for that... First, prior to u-boot
v2012.04.01, u-boot could only load from either a fat16 or ext2
partition... ext2, isn't that great for a full rootfs, so that option
is really out the window.. So we need atleast 2 partition... 2nd, now
for nandless devices (BeagleBoard-xM) we need to stick the 2nd stage
bootloader (after the internal bootrom) MLO/u-boot on fat16
partition..
So going down the road, as u-boot ext4 has gotten much better
(specially heading to v2012.07 its slow in v2012.04.01), we are
probably going to be switching to loading the boot files from /boot/
(on the ext3/4 rootfs) instead of the fat16 partition.. But for btrfs
users, they'll still have to stick with the older method..
I'm using Debian wheezy because its stable, yet up-to-date enough to work
with hardware that beagleboard offers; I don't use a GUI either (in fact I'm
not even taking advantage of either s-video or DVI-d). Considering Ubuntu
uses newer kernels where Canonical is the main source of performance
improvements, and considering that Ubuntu has much shorter stable cycles
than Debian, would you consider it to be a better option for me to move to
Ubuntu instead? Perhaps that may fix this weird serial port problem, too.
I think, the ubuntu/linaro guys do have much more resources at their
disposal to work on this hardware, so you will see faster/newer
improvements there first.. But at the same point, for armel/armhf
stuff, a lot of the system libraries and gcc goes back to debian
pretty quickly.. However as a counter point, the initial ubuntu
'armhf' port actually came from the initial work by a debian developer
working on improving their freescale based imx51 hardware for running
debian. 
btw, just so you don't loose your mind, if you switch to the ubuntu
beagleboard image from my site, rcn-ee.net, it uses the exact same
kernel.. so the weird serial port problem should occur there too..
Regards,