[beagleboard] Debian armhf problems

I used the pre-made Debian wheezy armhf image for Beagleboard, which overall
seems to work just fine, however I've got a few problems all of which seem
linked to each other:

1. I want to use the serial port to communicate to an arduino. I don't have
it boot to a console, /dev/ttyO2 shows up but nothing happens. I do have it
connected properly. setserial -g seems states UART is inactive, the port is
0x0000, but the IRQ is 78 (I think that's what it was, I can't remember off
the top of my head).

/dev/ttyO2, is the default serial boot console, disable getty in
"/etc/initab" and it'll be easier to use directly with the Arduino, or
use one of the other 2 uarts..

2. I thought it may have something to do with the kernel itself, and I found
out I've got 2 different kernels installed (3.2.0-psp6 and 3.2.13-x7) when
apt-get doesn't recognize either of those being installed.

3.2.0-psp6 is for BeagleBone hardware..
3.2.13-x7 is for BeagleBoard/PandaBoard hardware..

(two kernels is just a stop gap till, the BeagleBone is better support
mainline)..

3. I installed 3.2.0-2-omap and u-boot, but neither of those are recognized

3.2.0-2-omap, is a pure "debian" kernel, talk them about 'supporting'
the BeagleBoard-xM... (I've dealt with enough bugs when
Linaro/Ubuntu/Fedora try to support the Beagle Hardware..)

by the first partition - it seems as though the image I used to set up
beagleboard installed the 2 kernels and uboot by other means, in a manner
that isn't recognized by debian. I don't like this because that means
updating will become a hassle.

It was installed via dpkg.. and the vmlinuz was copied to the boot
partition "/boot/uboot" as zImage... Debian's scripts are probally
trying to dump an older "uImage" in some random boot directory..

As for 'updating' normally in embedded systems you NEVER update the
kernel, so the kernel used in the "demo" image will hever be "apt-get
upgradeable"... But if you'd like to upgrade to the latest "stable"
just follow:

http://elinux.org/BeagleBoardDebian#Beagleboard:_Install_Latest_Kernel

So, how can I force the omap kernel to be used, remove the other 2 kernels,
and get the serial port to work with the arduino? I don't mind taking this
question 1 step at a time.

Simple... Install the 3.2.0-2-omap image.. copy the "vmlinuz-3.2.0-2"
to /boot/uboot/zimage then run "sudo update-initramfs -ck
3.2.0-2-omap"... After that, any kernel support would be from
debian-arm/debian-kernel, and not this list... sorry...

Regards,

/dev/ttyO2, is the default serial boot console, disable getty in
"/etc/initab" and it'll be easier to use directly with the Arduino, or
use one of the other 2 uarts..

It is disabled in inittab. I'd gladly use one of the other 2 uarts if I
knew where they were located but I can't seem to get a direct answer about
that - the Beagleboard manual is both very detailed and extremely vague at
the same time. Besides, I believe they too are getting similar results when
using setserial.

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

3.2.0-psp6 is for BeagleBone hardware..
3.2.13-x7 is for BeagleBoard/PandaBoard hardware..
(two kernels is just a stop gap till, the BeagleBone is better support
mainline)..

So, should I just delete the psp6 and stick with the x7?

They are both installed via dpkg, but only the "x7" is enabled for
boot use, when you ran "setup_sdcard.sh" with the "--uboot beagle_xm"
option this placed the "x7" "uImage/uInitrd" or "zImage/initrd.img"
(some demo images have been transition to zImage) pare to the
/boot/uboot/

Also, how do I update the x7?

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)

3.2.0-2-omap, is a pure "debian" kernel, talk them about 'supporting'
the BeagleBoard-xM... (I've dealt with enough bugs when
Linaro/Ubuntu/Fedora try to support the Beagle Hardware..)

Would using this be better or worse than the x7? In the end, all I really
want is something that can stay up to date using apt-get or a fairly
straight-forward script.

It was installed via dpkg.. and the vmlinuz was copied to the boot
partition "/boot/uboot" as zImage... Debian's scripts are probally
trying to dump an older "uImage" in some random boot directory..

uImage appears to be the default being used and I don't recall ever changing
anything to cause that. If I remove zImage, it still boots successfully.
I'm not sure if FAT16 is capable of this but wouldn't it be easier to do a
symlink to the /boot directory of the 2nd partition, so apt-get/aptitude can
automatically update everything?

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)

As for 'updating' normally in embedded systems you NEVER update the
kernel, so the kernel used in the "demo" image will hever be "apt-get
upgradeable"... But if you'd like to upgrade to the latest "stable"
just follow:

I see, do you mind me asking why this is frowned upon? I sincerely want to
know, because depending on the reason then I won't have a problem with
sticking with 1 kernel all the time.

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

https://github.com/RobertCNelson/stable-kernel/commits/master/

http://elinux.org/BeagleBoardDebian#Beagleboard:_Install_Latest_Kernel

This applies to armhf too?

Oh, yeap, need to update that use..

export DIST=wheezy
export ARCH=armhf

So, how can I force the omap kernel to be used, remove the other 2
kernels,
and get the serial port to work with the arduino? I don't mind taking
this
question 1 step at a time.

Simple... Install the 3.2.0-2-omap image.. copy the "vmlinuz-3.2.0-2"
to /boot/uboot/zimage then run "sudo update-initramfs -ck
3.2.0-2-omap"... After that, any kernel support would be from
debian-arm/debian-kernel, and not this list... sorry...

Ok cool. But just to be clear - are you recommending me not do this? Also,
this will still work regardless of the separate FAT16 partition?

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

Regards,

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?

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.

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? Also, since it did reference uImage, what does that mean for me? Will running that script fix everything?
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.

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.

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.

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.

Again, thanks for the info and patience.

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

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,

So I did try the ubuntu variant (which to my surprise is much better than the debian one, I normally hate ubuntu) and there’s still a serial problem but not the same one. I once again removed ttyO2 from inittab and uEnv.txt, serterial still returns:

/dev/ttyO2, UART: undefined, Port: 0x0000, IRQ: 74

which is the same as before. However the 1 difference is this time a python script I run will actually halt waiting to receive serial data, where it did not do this when running debian (it just ignored that there was no data and would continue the loop, even though it wasn’t actually receiving anything)

That beaglebone reference you sent me doesn’t seem to be much help, because the pin headers on that do not match the headers in the xm manual, and the serial i/o section is either out of date or doesn’t apply to xm. Besides, it wasn’t explicitly clear on how to enable RX, TX, and DTR.