How newbie got Ångström demo working
johnb...@yahoo.com
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.
EMBES_Nathanan Srisa-ard
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.
2008/8/7 <johnb...@yahoo.com>:
rober...@apostrophe.co.uk
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.
John Beetem
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.
j...@scoteid.com
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
On Sep 10, 9:13 pm, John Beetem <johnbee...@yahoo.com> wrote:
> Hi Robert,
>
> The remaining steps are the standard steps described in the
> pages that it references such as Google Codehttp://code.google.com/p/beagleboard/w/list.
Jason Kridner
> 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
>
> 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)
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.
Mighty Blocksman
PLEASE HELP
Gerald Coley
Kevin Uhlir
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
Terrence
Gerald Coley
DOUAT Laurent
I found an already existing :
FATAL: Module uinput not found.
Måns Rullgård
> 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.
--
Måns Rullgård
ma...@mansr.com
Måns Rullgård
> On Mon, Nov 3, 2008 at 6:38 PM, Terrence <terr...@bayworld.com> wrote:
>
>> 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.
--
Måns Rullgård
ma...@mansr.com
Jim Stewart
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.
Kevin Uhlir
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
Måns Rullgård
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
ma...@mansr.com
Bill Gatliff
>
> 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.
--
Bill Gatliff
bg...@billgatliff.com
Kevin Uhlir
> -----Original Message-----
> From: beagl...@googlegroups.com
> [mailto:beagl...@googlegroups.com] On Behalf Of Bill Gatliff
> Sent: Tuesday, November 04, 2008 11:36 AM
> To: beagl...@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
> bg...@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
Bill Gatliff
>
> 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.
Ext3 is probably similar enough, and you'd get the journaling benefit as well.
But yea, I'd definitely schedule replacement--- and when picking the replacement
candidate buy two and abuse the daylights out of one first to see what happens.
I have seen a couple of SD/MMC controllers get completely hung up on an error,
to the point that you just pitch the card. Little postage-stamp-sized
doorstops, as I remember it.
> I assume jffs2 would be the right choice for a rootfs on the nand flash on the board.
Yes, or perhaps yaffs. I haven't had time to look at the UBI stuff, maybe
there's something there too.
> However if I mounted it read-only I could still choose ext2 for performance
reasons.
True, if you could create the image offline and then dd it into the device.
For read throughput, once you're mounted the performance difference might not be
all that different between ext* and the various *ffs*-en, because the kernel's
VFS stuff works to your advantage for both. JFFS has a reputation for slow
mounting, but "summary nodes" can speed that up if you enable that feature. If
your system even cold-boots at all, I mean--- most of my platforms are up so
long, the reboot time doesn't matter because it's only done a few times a year.
I'd probably go with one of the ffs-en rather than ext even in a presumed
read-only scenario. Because then if you changed your mind later about
read/write you wouldn't have to reconfigure the system--- just remount if
necesssary, and you're good to go.
Mark Grosen
Mark
j...@scoteid.com
I've not noticed any problems yet although it is very early days.
On Nov 3, 8:07 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> On Oct 21, 1:34 pm, j...@scoteid.com wrote:
>
>
>
> > 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