How newbie got Ångström demo working

I got my BeagleBoard B.4 a week ago and today finished getting Koen's
awesome Ångström demo working. I thought it might be useful to list
some of the bits of lore I picked up from various postings in this
group and elsewhere to help others.

First, my primary development platform is Windows 2000 rather than
Linux, and for various reasons I'd like to keep it that way. I think
Cygwin provides the Linux tools I need for development. Windows
presented some interesting challenges.

1. The Beagle Hardware Reference B.4 is excellent. It's probably the
best hardware description I've ever seen and contains a wealth of
information.

2. You need a good +5V supply. Beware of cheap unregulated bricks in
your collection of surplus parts as they could fry your board. The
voltage regulators on the BeagleBoard are rated for maximum +5.5V
inputs and could burn out with a bad supply.

3. Ångström needs to use the USB OTG port in host mode with an
external USB hub for keyboard, mouse, and any other USB peripherals.
This requires the BeagleBoard to be powered from the +5V power jack.
You'll probably also need external power for the USB hub as well,
because according to the Hardware Reference the BeagleBoard OTG port
only sources 100 mA. I found this out the hard way. Ångström worked
great with just a keyboard, or with just a hub and a mouse, but
plugging in all three caused Ångström to generate a lot of strange
error messages as it continuously unlinked and relinked the keyboard.
Externally powering the hub fixed this nicely.

4. The Linux kernel needs to know you want to use the OTG port in host
mode. I believe OTG ports are supposed to figure this out for
themselves, but for now the Linux kernel needs some help.
Specifically, Pin 4 (ID) of the OTG connector needs to be shorted to
Pin 5 (GND), either in the cable (preferred) or on the board (if you
never want to use the port in device mode). For the present, I short
the two pins together with a probe while Linux boots. Once the boot
is complete, I can remove the probe. [Thanks, Nathanan! This would
have been very hard to find on my own.]

5. Preparing the two-partition SD card was interesting. Since my
development system is Windows 2000, there was no way to produce an
ext3 partition for Linux and transfer the files over. I first tried
to see if I could untar the file system as FAT32 and change the
bootargs, but either I don't have the bootargs right or it's simply
impossible. What I ended up doing was getting a couple of free Ubuntu
CD ROMs at Linux World which allow me to boot Ubuntu or Kubuntu
directly from the CD ROM without changing Windows. It's slow, but it
was a safe way to run Linux. [Thank you, Bill, for suggesting this.]

I had problems with Ubuntu 8.04.1 LTS Desktop Edition. While I could
run fdisk without any problems (they called the SD card /dev/sdb on my
PC), they didn't seem to have a driver for the second partition so I
couldn't untar the root file system.

Kubuntu 8.04 was successful. I was able to copy MLO, uBoot, and
uImage into Partition 1 (/dev/sdb1) and untar the root file system
into partition 2 (/dev/sdb2).

6. Almost there! Alas, the BeagleBoard could not find MLO in
Partition 1, even though it was quite nicely there at the beginning
when I listed the files. I even tried deleting all three files (MLO,
uBoot, and uImage) and recopying them. BeagleBoard still could not
find MLO.

Here's what finally worked: I reformatted Partition 1 under Windows
and then copied MLO, uBoot, and uImage. I believe the problem was
that MLO must be in the first sector of the partition. If you don't
reformat, the FAT file system may put the file anywhere. If I cared,
I'd investigate further how FAT works but for now it's no big deal to
reformat before copying. Just make sure you reformat the SD card and
not your hard drive.

Happy beagling, everyone.

Hello,

I could not find USB hub with DC power and never seen OTG USB cable at
local shop .
I did solder a little jumper at usb pint 5-Gnd at beagleboard and
make a DC USB injector myself.
see the picture at
http://developer.embes.com/blog/wp-content/uploads/2008/08/09082008007.jpg
this will isolate DC from USB hub to OTG. My 1.1 USB hub not work
with beagle, I have to buy a new one.

http://developer.embes.com/blog/wp-content/uploads/2008/08/09082008004.jpg
Internet connection using GPRS on /dev/ttyACM0 (Nokia cell phone at
USB port) woks well, I
will try Bluetooth on /dev/ttyBTx another day.

Hope will help another newbie like me.

Nathanan.

John,

Thanks for that, but it doesn't explain how you then got Ångström
going on the demo! Any chance of taking us through the last step?

Many thanks.

Hi Robert,

The remaining steps are the standard steps described in the
BeagleBoard wiki http://elinux.org/BeagleBoard#Binaries and other
pages that it references such as Google Code http://code.google.com/p/beagleboard/w/list.
My post above listed lore that was not available from these sources or
the BeagleBoard FAQ at that time.

You have to follow the wiki and Google Code steps very carefully. I
found it useful to print the Google Code pages I needed so I could
highlight key inputs and outputs carefully. Sometimes you have to use
the documents as a guide rather than copying verbatim. For example,
the LinuxBootDiskFormat page uses /dev/sdc for the SD card, but the
Kubuntu Linix I used called it /dev/sdb. I found this from the Linux
"mount" command, which lists all mounted disks.

Given the large number of Linux and other development platforms, it is
pretty much impossible to write step-by-step instructions that cover
all cases. It's best to make sure you understand what is supposed to
happen in each step so you can find a way to make that happen.

I hope this and other threads have helped.

Cheers John you've saved me hours of frustration trying to figure out
the USB OTG silliness.

For those interested I've written some simple instructions on the
method I've used to get Angstrom working. It is very similar to the
method at http://elinux.org/BeagleBoardBeginners but is easier for
those that don't enjoy command line hacking / maths.

1. Download the Angstrom beagle demo images on to a usb stick
    http://www.angstrom-distribution.org/beagleboard-demo-image-available
2. Download and install the HP boot disk HP USB Disk Storage Format
Tool (in windows)
    HP USB Disk Storage Format Tool
3. Format your MMC as a FAT drive using the HP tool
4. Now copy MLO FIRST onto the the MMC then uImage and u-boot.bin
5. Fire up Linux. If you don't have a linux computer download a live
cd instead such as puppy linux.
6. Open the linux partitioning tool (gparted or whatever) and resize
the FAT drive to ~50M (approximately the minimum limit)
8. Now is a good time to test that what you have done is working. If
you plug in the card hold the user button and switch on hopefully if
you have the serial port connected you will get the boot info or if
not then the two side by side USR LEDs should light up. If neither
happens then there is a problem and you will have to retry the
previous steps.
9. Now create a Linux ext2/ext3 partition in the remaining space on
the MMC
10. Untar the Angstrom distribution into the linux partition
11. Fire up the beagle board using a serial connection and
hyperterminal/minicom etc. and enter the following commands
     setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
rootwait'
     setenv bootcmd 'mmcinit;fatload mmc 0 80300000 uImage;bootm
80300000'
     saveenv
12. Get really frustrated by the keyboard and mouse not working until
reading this thread

Cheers

Cheers John you've saved me hours of frustration trying to figure out
the USB OTG silliness.

For those interested I've written some simple instructions on the
method I've used to get Angstrom working. It is very similar to the
method athttp://elinux.org/BeagleBoardBeginnersbut is easier for
those that don't enjoy command line hacking / maths.

1. Download the Angstrom beagle demo images on to a usb stick
http://www.angstrom-distribution.org/beagleboard-demo-image-available
2. Download and install the HP boot disk HP USB Disk Storage Format
Tool (in windows)
HP USB Disk Storage Format Tool
3. Format your MMC as a FAT drive using the HP tool
4. Now copy MLO FIRST onto the the MMC then uImage and u-boot.bin
5. Fire up Linux. If you don't have a linux computer download a live
cd instead such as puppy linux.
6. Open the linux partitioning tool (gparted or whatever) and resize
the FAT drive to ~50M (approximately the minimum limit)

If you repartition your disk and do not reformat the FAT partition, it
will contain invalid formatting information. This may work fine, but
will report wrong information to your operating system, ultimately
resulting in loss of data if you manipulate that partition.

Once I switched to NAND my BB bricked. No output on any interface. Is there a way for me to flash a revb back to its initial state so I can start over?

PLEASE HELP

Try this http://elinux.org/BeagleBoardRecovery

Gerald

This is not a beagleboard specific question, but, if anyone knows, any experience is appricated.

One of my projects for beagle will have it running constantly for literally years. It probably won’t be changed hardware wise for 5+ years, and only minor software changes during that time.

Part of its job will be to collect statistics, via log files, etc. Periodically (daily) it will send the collected data, and simple analysis reports to an email server. My inital thought is to have the rootfs on a SD card. Does anyone have experience or a reaction to using the SD card as a rootfs that is being used actively to store and cleanup data (as opposed to mostly read-only)? Will I run into a wear out issue? There’s no easy way to tell if the internal wear leveling of the SD card is working well or not. Maybe a “larger” SD card will last longer (if wear leveling actually works inside the sd card)? I’m only generating 2 to 4 MegaBytes of data daily.

Any insights are appricated.

Kevin

Beagleboard was not designed for final application…!!! only for experimental testing and proof of concept geared mainly for students, Holiest and alike. You will need more put into the final board application design, meant to last 24/7 operation.
What kills electronics is heat, static, moisture and vibration. You must pay tricked attention to Heat and static… along with FCC Part 15 certification for general industrial use… all this must be build into you final design… We have already hosed three Beagleboards with these issues in testing, other than those issues Beagleboards Rock! :wink:

Also, FLASH memory is limited to 10,000 writes per block. So, at the least you need to make sure you move the data around a lot to insure you are not writing to the same blocks over and over. This adds to the complexity of using a file system in FLASH.

Gerald

Hello,

I am trying to use the kernel module named uinput.
With googling, I find out that it must be activated in the kernel
Does somebody know which precise variable must be set.
I found an already existing :
CONFIG_INPUT_MOUSE=y

But
oot@beagleboard:~# modprobe uinput
FATAL: Module uinput not found.

Thanks

Laurent

"Kevin Uhlir" <kevinu@flochart.com> writes:

This is not a beagleboard specific question, but, if anyone knows, any
experience is appricated.

One of my projects for beagle will
have it running constantly for literally years. It probably
won't be changed hardware wise for 5+ years, and only minor software
changes during that time.

The OMAP3530 chip is rated for 100k power-on hours (~11 years), which
drops to 50k hours if running at full speed/voltage.

Part of its job will be to collect
statistics, via log files, etc. Periodically (daily) it will send
the collected data, and simple analysis reports to an email
server. My inital thought is to have the rootfs on a SD
card. Does anyone have experience or a reaction to using the SD card
as a rootfs that is being used actively to store and cleanup data (as
opposed to mostly read-only)? Will I run into a wear out
issue? There's no easy way to tell if the internal wear leveling of
the SD card is working well or not. Maybe a "larger"
SD card will last longer (if wear leveling actually works inside the sd
card)? I'm only generating 2 to 4 MegaBytes of data
daily.

Modern flash memory is typically rated for 100k erase/write cycles per
block. If you could spread the writes evenly, writing 4 MB per day to
a 4GB card would write each block every 1k days, or roughly 3 years.
The question is whether something causes frequent writes to some
block. I wouldn't trust the built-in wear levelling to work
perfectly, mostly since I have no idea how it actually works.

If your logs are the only things being written regularly, you can
easily do your own levelling. Simply pre-allocate a huge file, and
use it as a ring buffer. If each record contains a timestamp, there
is no need a store the current position separately. A modified binary
search will find it quickly.

Design the file format properly, and the SD card will probably be the
last component to fail.

"Gerald Coley" <gerald@beagleboard.org> writes:

Måns Rullgård wrote:

"Gerald Coley" <gerald@beagleboard.org> writes:

This is not a beagleboard specific question, but, if anyone knows,
any experience is appricated.

One of my projects for beagle will have it running constantly for
literally years. It probably won't be changed hardware wise for 5+
years, and only minor software changes during that time.

Part of its job will be to collect statistics, via log files, etc.
Periodically (daily) it will send the collected data, and simple
analysis reports to an email server. My inital thought is to have
the rootfs on a SD card. Does anyone have experience or a reaction
to using the SD card as a rootfs that is being used actively to
store and cleanup data (as opposed to mostly read-only)? Will I
run into a wear out issue? There's no easy way to tell if the
internal wear leveling of the SD card is working well or not.
Maybe a "larger" SD card will last longer (if wear leveling
actually works inside the sd card)? I'm only generating 2 to 4
MegaBytes of data daily.

Also, FLASH memory is limited to 10,000 writes per block. So, at the
least you need to make sure you move the data around a lot to insure
you are not writing to the same blocks over and over. This adds to
the complexity of using a file system in FLASH.

The POP flash on the Beagle board claims 100k write cycles. The specs
for SD cards probably vary. Regardless, flash wear is an issue that
needs to be addressed.

For what it's worth, I have considerable experience
with small sector NOR flash and almost none with NAND.

That said, there's an important characteristic of
flash that data sheets don't address. That is a
"cooling off" phenomenon. We have found that SST
NOR flash has a virtually unlimited life providing
you wait at least 15 to 20 minutes between writes
to the same sector. SST has verbally confirmed our
observations, but refuses to specify the phenomenon.

That said, If I were writing a long-term data logging
ap, I'd be sure to observe the cooling off period
between writes to the same sector.

Thank you, I appreciate the very useful on-point responses. Especially the
cpu power-on hours, which I don't believe I would have found on my own.

Regarding SD card built in wear leveling, "we don't really know how it
works" is the answer most folks have, including the manufacturers reps. I'd
like to keep the logging simple, and a ring would be simple. The other
alternative is to run jffs2 on the SD card, however, most folks with an
opinion have said that’s a bad idea. If the size of the rootfs permits, I
might run most of the system in the built in flash, and use the SD card only
for logging, and other changing data, then schedule the card for copy and
replacement once per year. Is there a spec on the retention time of the pop
flash?

Since this project is a "one off" project, it sounds like it would be
prudent to simply have a spare beagle ready to go into place when needed.

Kevin

Kevin Uhlir wrote:

Thank you, I appreciate the very useful on-point responses. Especially the
cpu power-on hours, which I don't believe I would have found on my own.

Regarding SD card built in wear leveling, "we don't really know how it
works" is the answer most folks have, including the manufacturers reps. I'd
like to keep the logging simple, and a ring would be simple. The other

Suspicious mode on, since we don't know how the wear levelling works,
we can't be certain that a ring structure isn't the worst thing you could
possibly do to it. It is conceivable that a specific pattern of writes
completely defeats the built-in levelling algorithm, and ends up writing
the same block far more often that expected.

It may seem far-fetched, but you never can tell for sure. I've seen
hard drives killed by too frequent SMART queries.

alternative is to run jffs2 on the SD card, however, most folks with an
opinion have said that’s a bad idea.

JFFS2 is designed for raw flash devices without any built-in wear levelling.
Using it on a device with wear levelling is unnecessary at best.

If the size of the rootfs permits, I might run most of the system in the
built in flash,

The 256MB onboard flash should be plenty for a simple sensor logger.

and use the SD card only
for logging, and other changing data, then schedule the card for copy and
replacement once per year. Is there a spec on the retention time of the pop
flash?

10 years, IIRC.

Måns Rullgård wrote:

Suspicious mode on, since we don't know how the wear levelling works,
we can't be certain that a ring structure isn't the worst thing you could
possibly do to it. It is conceivable that a specific pattern of writes
completely defeats the built-in levelling algorithm, and ends up writing
the same block far more often that expected.

Since most SD/MMC cards are sold for things like digital camera applications,
and such devices tend to use VFAT, whatever is in the card that passes for a
wear-leveling algorithm--- if any--- is probably tuned to work best for that
filesystem. If you depart significantly from that, you might be asking for
problems.

JFFS2 would be a particularly bad choice regardless, since it's designed for a
completely different medium altogether.

b.g.

How critical is the data? How reliable do you expect the overall system to be? If acceptable in terms of risk of losing data, why not use a tmpfs (ram disk) to store the data? If it’s only 4MB/day and you upload it each day, a small ram disk would hold the data and you avoid any problems with flash wearing.

Mark

See below:

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Bill Gatliff
Sent: Tuesday, November 04, 2008 11:36 AM
To: beagleboard@googlegroups.com
Subject: [beagleboard] Re: Experience with flash "wear out"

Måns Rullgård wrote:
>
> Suspicious mode on, since we don't know how the wear levelling works,
> we can't be certain that a ring structure isn't the worst thing you
could
> possibly do to it. It is conceivable that a specific pattern of
writes
> completely defeats the built-in levelling algorithm, and ends up
writing
> the same block far more often that expected.

Since most SD/MMC cards are sold for things like digital camera
applications,
and such devices tend to use VFAT, whatever is in the card that passes
for a
wear-leveling algorithm--- if any--- is probably tuned to work best for
that
filesystem. If you depart significantly from that, you might be asking
for
problems.

Vfat..hmmm... well I could use that for the logs. Since log files would be somewhat "similar" to writing pictures sequentially, which is what the camera would do, it should fit their "possibly simple or non-existant leveling method".

I don't see vfat supporting anything like data=ordered for ext3. I'm left with the sync option. I'm still thinking I might beat the wear-out issue by simply scheduling copy and replacement once a year, then give away the old SD card to some unsuspecting person. Still I think I'll take the vfat advice in combination with scheduled replacement.

JFFS2 would be a particularly bad choice regardless, since it's
designed for a
completely different medium altogether.

I assume jffs2 would be the right choice for a rootfs on the nand flash on the board. However if I mounted it read-only I could still choose ext2 for performance reasons. I have yet to determine exactly how much of the file system will actually be changing over time.

b.g.
--
Bill Gatliff
bgat@billgatliff.com

FYI, this project does more than just log. It controls various devices, sends audio periodically, response to commands, etc. It'll be used as the "fancy" part of an amateur radio repeater, providing all of the high level features. Updates at the beginning of the project will be often (mainly to the main program that controls everything, and updating various sound files), but later very infrequently.

We've had a PC based Linux system in place for this purpose, which hasn't changed much (except for hardware failures) since 1994. Our other choice is to simply use a PC again, which at this point seems like overkill. The beagleboard seems a good replacement, low cost, low power, no moving parts, smaller, less heat. We're also adding a bunch of additional features at the same time, and reducing the size of the whole controller (beagle plus, low level controller, interfaces to link receivers, etc) to a 1U rack space. One can think of this as a robotics project, except nothing moves.

I had started this project with the Gumstix Verdex in mind, but when I saw the beagleboard had pretty much everything on the one board, it seemed a better choice. Now that Gumstix is putting all their eggs into the Overo bucket, I'll look at that again when it matures (for other projects), since I don't need to buy another board for audio, display, etc with beagleboard it’s a better choice for this one-off project.

Again, I appreciate all the advice.

Kevin