New SD card image to test

1,338 views
Skip to first unread message

Koen Kooi

unread,
Mar 10, 2011, 10:35:51 AM3/10/11
to beagleboard@googlegroups.com Board
Hi,

With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:

http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz

Installing it is just a matter of 'zcat validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz > /dev/sdX', where 'X' is the drive letter of your SD card.

regards,

Koen

Steve Sakoman

unread,
Mar 10, 2011, 10:59:06 AM3/10/11
to beagl...@googlegroups.com
On Thu, Mar 10, 2011 at 7:35 AM, Koen Kooi <ko...@beagleboard.org> wrote:
> Hi,
>
> With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:

Any significant changes in revision C? Does it require changes to
x-load, u-boot, or kernel?

Steve

Koen Kooi

unread,
Mar 10, 2011, 11:15:05 AM3/10/11
to beagl...@googlegroups.com

Op 10 mrt 2011, om 16:59 heeft Steve Sakoman het volgende geschreven:

> On Thu, Mar 10, 2011 at 7:35 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>> Hi,
>>
>> With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
>
> Any significant changes in revision C?

EHCI power got inverted again.

> Does it require changes to
> x-load, u-boot, or kernel?

Yes, no, yes. Jason is going to send the MLO change upstream, the kernel patch will need some reworking: http://dominion.thruhere.net/koen/angstrom/beagleboard/0001-beagleboard-hack-in-support-from-xM-rev-C.patch

Uboot now supports uEnv.txt and will load uImage from ext3 instead of vfat.

regards,

Koen


>
> Steve
>
> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>

Steve Sakoman

unread,
Mar 10, 2011, 11:22:52 AM3/10/11
to beagl...@googlegroups.com
On Thu, Mar 10, 2011 at 8:15 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>
> Op 10 mrt 2011, om 16:59 heeft Steve Sakoman het volgende geschreven:
>
>> On Thu, Mar 10, 2011 at 7:35 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>>> Hi,
>>>
>>> With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
>>
>> Any significant changes in revision C?
>
> EHCI power got inverted again.

Sigh

>> Does it require changes to
>> x-load, u-boot, or kernel?
>
> Yes, no, yes. Jason is going to send the MLO change upstream, the kernel patch will need some reworking: http://dominion.thruhere.net/koen/angstrom/beagleboard/0001-beagleboard-hack-in-support-from-xM-rev-C.patch
>
> Uboot now supports uEnv.txt and will load uImage from ext3 instead of vfat.

What is the reason for the kernel location change? Is there an
obvious advantage that makes up for the confusion that this change
will cause (i.e. a gazillion more instantly out of date wikis)?

Steve

Robert Nelson

unread,
Mar 10, 2011, 11:27:09 AM3/10/11
to beagl...@googlegroups.com

so u-boot actually now "correctly" reads the uImage file off the ext3 partition?

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

Koen Kooi

unread,
Mar 10, 2011, 11:42:26 AM3/10/11
to beagl...@googlegroups.com, beagl...@googlegroups.com

Package upgrades work and the kernel matches the fs.

And wikis are out of date by definition

Koen Kooi

unread,
Mar 10, 2011, 11:44:02 AM3/10/11
to beagl...@googlegroups.com, beagl...@googlegroups.com

It does over here and at Jasons as well :) It even follows symlinks!


>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

Gary Thomas

unread,
Mar 10, 2011, 12:03:44 PM3/10/11
to beagl...@googlegroups.com, Koen Kooi

Fails on rev C3
[ 3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
[ 4.274261] Waiting for root device /dev/mmcblk0p2...
[ 6.636322] mmc0: error -110 whilst initialising SD card

Also still fails to find anything on EHCI (hub, external power)

Note: I had to erase my U-Boot environment via 'nand erase 260000 20000'

--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------

Gary Thomas

unread,
Mar 10, 2011, 12:09:01 PM3/10/11
to beagl...@googlegroups.com, Koen Kooi
On 03/10/2011 10:03 AM, Gary Thomas wrote:
> On 03/10/2011 08:35 AM, Koen Kooi wrote:
>> Hi,
>>
>> With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
>>
>> http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz
>>
>> Installing it is just a matter of 'zcat validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz> /dev/sdX', where 'X' is the drive letter of your SD card.
>
> Fails on rev C3

To be clear, original BeagleBoard (not xM) rev C3

Jason Kridner

unread,
Mar 10, 2011, 3:51:05 PM3/10/11
to beagl...@googlegroups.com
On Thu, Mar 10, 2011 at 12:09 PM, Gary Thomas <ga...@mlbassoc.com> wrote:
> On 03/10/2011 10:03 AM, Gary Thomas wrote:
>>
>> On 03/10/2011 08:35 AM, Koen Kooi wrote:
>>>
>>> Hi,
>>>
>>> With the imminent release of the BeagleBoard xM revision C we needed to
>>> do a new SD image. RC5 can be downloaded here:
>>>
>>>
>>> http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz
>>>
>>> Installing it is just a matter of 'zcat
>>> validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz> /dev/sdX', where 'X'
>>> is the drive letter of your SD card.
>>
>> Fails on rev C3

It works for me.

>
> To be clear, original BeagleBoard (not xM) rev C3

I have a non-xM C3 with a Zippy attached. I saw a strange behavior
where if I had a card in the SD slot of the Zippy, it mounted it as
root.

>
>> [ 3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
>> [ 4.274261] Waiting for root device /dev/mmcblk0p2...
>> [ 6.636322] mmc0: error -110 whilst initialising SD card

We likely need to patch it to support longer timeouts. There are some
patches out there for this. It worked for me at first, but then the
error started to show up for me. I'm not sure what changed other than
I finished the initial configuration run and rebooted.

>>
>> Also still fails to find anything on EHCI (hub, external power)

This worked fine for me. Any details on the failure mode? What do
you mean by "still"? If you know about the EHCI issues faced with
non-xM C3 boards, have you self-modified the board to fix the issue?
Most C3 boards, including the one I have, never had an issue with the
EHCI, but some did have some intermittent problems.

Anyway, I didn't have any problem with my external USB hub + keyboard
and mouse (tried without powering the hub).

>>
>> Note: I had to erase my U-Boot environment via 'nand erase 260000 20000'

To avoid that problem in the future, I think we need a quick patch to
put reading the environment variables from NAND to be a command,
rather than part of the initialization. This command would need to be
executed by default, but the boot command would not be overwritten
without reading user.txt when the user button is held.

Any other changes besides the MMC patch that need to go into this
before we recommend CircuitCo pull the image down for testing and
demoing the new BeagleBoard version?

Stretch goals and tweaks
* Anybody try the DFU patch and care to submit it to Angstrom?
* Anybody consolidating the networking patches to keep the Ethernet
MAC constant. I'd be happy with something that used the die id, but
it needs to be done such that it falls into manufacturer and device
region that won't be occupied. Ideally, it would also be possible to
pass in a MAC address on the kernel command line.
* Anybody try some of the EDID hacks or have good fixes in mind for them?
* What are those launch icons on the top bar that are empty?
* Some "echo dvimode=[resolution] >> /media/boot/uEnv.txt" (or perl
-pi.bak -e "s/.../.../" like) method via a menu option or something?

user.txt

Jim Norton

unread,
Mar 10, 2011, 7:33:42 PM3/10/11
to beagl...@googlegroups.com
Do any of the test builds are any kernel/ distribution sets come setup
to support the various extension cards for the -xM such as the
TinCanTools Trainer board?

----- Message from jkri...@beagleboard.org ---------
Date: Thu, 10 Mar 2011 15:51:05 -0500
From: Jason Kridner <jkri...@beagleboard.org>
Reply-To: beagl...@googlegroups.com
Subject: Re: [beagleboard] New SD card image to test
To: beagl...@googlegroups.com

> --
> You received this message because you are subscribed to the Google
> Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to
> beagleboard...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/beagleboard?hl=en.
>
>


----- End message from jkri...@beagleboard.org -----

Dave N6NZ

unread,
Mar 10, 2011, 10:25:35 PM3/10/11
to beagl...@googlegroups.com, Koen Kooi

On Mar 10, 2011, at 9:03 AM, Gary Thomas wrote:
>>
>
> Fails on rev C3
> [ 3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
> [ 4.274261] Waiting for root device /dev/mmcblk0p2...
> [ 6.636322] mmc0: error -110 whilst initialising SD card

This failure may have nothing to do with a bug that is unique to this image. I have this error intermittently using one of RCN's example images. I posted a few days ago to this list with information that points to this being a boot-time race related to enabling preemption configs int the kernel.

Koen, What are your preemption settings in this kernel?

-dave

Robert Nelson

unread,
Mar 10, 2011, 10:35:57 PM3/10/11
to beagl...@googlegroups.com
On Thu, Mar 10, 2011 at 9:25 PM, Dave N6NZ <n6...@arrl.net> wrote:
>
> On Mar 10, 2011, at 9:03 AM, Gary Thomas wrote:
>>>
>>
>> Fails on rev C3
>> [    3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
>> [    4.274261] Waiting for root device /dev/mmcblk0p2...
>> [    6.636322] mmc0: error -110 whilst initialising SD card
>
> This failure may have nothing to do with a bug that is unique to this image.  I have this error intermittently using one of RCN's example images. I posted a few days ago to this list with information that points to this being a boot-time race related to enabling preemption configs int the kernel.
>
> Koen, What are your preemption settings in this kernel?

Thing is, i have a pile of mmc card's that works fine, and another
pile that give the -110 error on 2.6.37.. Turning preemption off seems
to fix it for most.. But what's weird, in 2.6.38-rc's the -110 error
can still occur, BUT boot still continues as it still finds the mmc
card.. (weird..)

Dave N6NZ

unread,
Mar 10, 2011, 11:14:06 PM3/10/11
to beagl...@googlegroups.com

Hmmm.... well.... maybe the preemption config setting is a red herring. That might just be a way to sensitize whatever is causing the issue (which smells like a race to me, but that is just a hunch.)

-dave

> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

Jason Kridner

unread,
Mar 10, 2011, 11:35:57 PM3/10/11
to beagl...@googlegroups.com
On Thu, Mar 10, 2011 at 11:14 PM, Dave N6NZ <n6...@arrl.net> wrote:
>
> On Mar 10, 2011, at 7:35 PM, Robert Nelson wrote:
>
>> On Thu, Mar 10, 2011 at 9:25 PM, Dave N6NZ <n6...@arrl.net> wrote:
>>>
>>> On Mar 10, 2011, at 9:03 AM, Gary Thomas wrote:
>>>>>
>>>>
>>>> Fails on rev C3
>>>> [    3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
>>>> [    4.274261] Waiting for root device /dev/mmcblk0p2...
>>>> [    6.636322] mmc0: error -110 whilst initialising SD card
>>>
>>> This failure may have nothing to do with a bug that is unique to this image.  I have this error intermittently using one of RCN's example images. I posted a few days ago to this list with information that points to this being a boot-time race related to enabling preemption configs int the kernel.
>>>
>>> Koen, What are your preemption settings in this kernel?
>>
>> Thing is, i have a pile of mmc card's that works fine, and another
>> pile that give the -110 error on 2.6.37.. Turning preemption off seems
>> to fix it for most.. But what's weird, in 2.6.38-rc's the -110 error
>> can still occur, BUT boot still continues as it still finds the mmc
>> card.. (weird..)
>>
>
> Hmmm.... well.... maybe the preemption config setting is a red herring.  That might just be a way to sensitize whatever is causing the issue (which smells like a race to me, but that is just a hunch.)

I threw in the timeout patch from Ubuntu's launchpad repository, but
it didn't seem to make an impact.

Are these the relevant .config settings?
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y

Any suggestions on alternative settings to try to make it a bit more stable?

Guess I should look up some owners for the MMC subsystem to see what
can be done to identify a root cause...

Dave N6NZ

unread,
Mar 10, 2011, 11:51:18 PM3/10/11
to beagl...@googlegroups.com

On Mar 10, 2011, at 8:35 PM, Jason Kridner wrote:

> On Thu, Mar 10, 2011 at 11:14 PM, Dave N6NZ <n6...@arrl.net> wrote:
>>
>> On Mar 10, 2011, at 7:35 PM, Robert Nelson wrote:
>>
>>> On Thu, Mar 10, 2011 at 9:25 PM, Dave N6NZ <n6...@arrl.net> wrote:
>>>>
>>>> On Mar 10, 2011, at 9:03 AM, Gary Thomas wrote:
>>>>>>
>>>>>
>>>>> Fails on rev C3
>>>>> [ 3.945098] mmci-omap-hs: probe of mmci-omap-hs.1 failed with error -16
>>>>> [ 4.274261] Waiting for root device /dev/mmcblk0p2...
>>>>> [ 6.636322] mmc0: error -110 whilst initialising SD card
>>>>
>>>> This failure may have nothing to do with a bug that is unique to this image. I have this error intermittently using one of RCN's example images. I posted a few days ago to this list with information that points to this being a boot-time race related to enabling preemption configs int the kernel.
>>>>
>>>> Koen, What are your preemption settings in this kernel?
>>>
>>> Thing is, i have a pile of mmc card's that works fine, and another
>>> pile that give the -110 error on 2.6.37.. Turning preemption off seems
>>> to fix it for most.. But what's weird, in 2.6.38-rc's the -110 error
>>> can still occur, BUT boot still continues as it still finds the mmc
>>> card.. (weird..)
>>>
>>
>> Hmmm.... well.... maybe the preemption config setting is a red herring. That might just be a way to sensitize whatever is causing the issue (which smells like a race to me, but that is just a hunch.)
>
> I threw in the timeout patch from Ubuntu's launchpad repository, but
> it didn't seem to make an impact.
>
> Are these the relevant .config settings?
> CONFIG_TREE_PREEMPT_RCU=y
> CONFIG_PREEMPT_RCU=y
> CONFIG_PREEMPT=y

I saw an email on LKML that said mmc0: error -110 went away by setting
CONFIG_PREEMPT=n

So to be completely honest, all I know about it is that some random person
that I've never met said CONFIG_PREEMPT=n made his system run better.
I haven't had time to pursue it yet, so I posted here to see if anyone else
knew anything about it.

My post of a few days ago contains a link to the LKML e-mail (which itself is
about 6 months old).

-dave

Robert Nelson

unread,
Mar 11, 2011, 12:12:14 AM3/11/11
to beagl...@googlegroups.com

for 2.6.37, this is what i've got enabled that seems to be working..

# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

Koen Kooi

unread,
Mar 11, 2011, 2:24:31 AM3/11/11
to beagl...@googlegroups.com, beagl...@googlegroups.com
Angstrom supports them all

Jim Norton

unread,
Mar 11, 2011, 9:13:30 AM3/11/11
to beagl...@googlegroups.com
Does that mean that the Angstrom distribution / kernel reads the
EEPROM ID on the expansion card and does the needed PIN Muxing etc?

Or must I still go about the task of doing the PIN Mux set up and then
tell the kernel about the SPI device etc?

Regards,
Jim


----- Message from ko...@beagleboard.org ---------
Date: Fri, 11 Mar 2011 08:24:31 +0100
From: Koen Kooi <ko...@beagleboard.org>


Reply-To: beagl...@googlegroups.com
Subject: Re: [beagleboard] New SD card image to test

To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Cc: "beagl...@googlegroups.com" <beagl...@googlegroups.com>


----- End message from ko...@beagleboard.org -----

Koen Kooi

unread,
Mar 11, 2011, 9:16:29 AM3/11/11
to beagl...@googlegroups.com

Op 11 mrt 2011, om 15:13 heeft Jim Norton het volgende geschreven:

> Does that mean that the Angstrom distribution / kernel reads the EEPROM ID on the expansion card and does the needed PIN Muxing etc?

It does exactly that for all known boards, e.g. zippy1, zippy2, trainer, beagletoys wifi, beaglefpga, etc.

Jim Norton

unread,
Mar 11, 2011, 9:22:48 AM3/11/11
to beagl...@googlegroups.com
Thanks for the information. Then do I just need to add some line of
code somewhere to tell the kernel about SPI so that I end with a
/dev/spi device? I have a bunch of /sys entries regarding SPI, but
nothing such as /dev/spi. Is it possible to interact with SPI directly
through /sys?

I have the following in sysfs:

root@beagleboard:/sys# find ./* -name spi*
./bus/spi
./bus/spi/drivers/spidev
./class/spi_master
./class/spi_master/spi1
./class/spi_master/spi2
./class/spi_master/spi3
./class/spi_master/spi4
./class/spidev
./devices/platform/omap2_mcspi.1/spi_master
./devices/platform/omap2_mcspi.1/spi_master/spi1
./devices/platform/omap2_mcspi.2/spi_master
./devices/platform/omap2_mcspi.2/spi_master/spi2
./devices/platform/omap2_mcspi.3/spi_master
./devices/platform/omap2_mcspi.3/spi_master/spi3
./devices/platform/omap2_mcspi.4/spi_master
./devices/platform/omap2_mcspi.4/spi_master/spi4
./module/spidev


Thanks again, I really appreciate the help.

----- Message from ko...@beagleboard.org ---------

Date: Fri, 11 Mar 2011 15:16:29 +0100

Jason Kridner

unread,
Mar 11, 2011, 9:18:27 PM3/11/11
to beagl...@googlegroups.com
On Thursday, March 10, 2011 11:42:26 AM UTC-5, Koen Kooi wrote:

Op 10 mrt. 2011 om 17:22 heeft Steve Sakoman <sak...@gmail.com> het volgende geschreven:

> On Thu, Mar 10, 2011 at 8:15 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>>
>> Op 10 mrt 2011, om 16:59 heeft Steve Sakoman het volgende geschreven:
>>
>>> On Thu, Mar 10, 2011 at 7:35 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>>>> Hi,
>>>>
>>>> With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
>>>
>>> Any significant changes in revision C?
>>
>> EHCI power got inverted again.
>
> Sigh
>
>>> Does it require changes to
>>> x-load, u-boot, or kernel?
>>
>> Yes, no, yes. Jason is going to send the MLO change upstream, the kernel patch will need some reworking: http://dominion.thruhere.net/koen/angstrom/beagleboard/0001-beagleboard-hack-in-support-from-xM-rev-C.patch
>>
>> Uboot now supports uEnv.txt and will load uImage from ext3 instead of vfat.
>
> What is the reason for the kernel location change?  Is there an
> obvious advantage that makes up for the confusion that this change
> will cause (i.e. a gazillion more instantly out of date wikis)?

Package upgrades work and the kernel matches the fs.

I'm looking forward to the FAT being eliminated all together.  I'm hopeful that the u-boot SPL code will enable us to use ext2/3 for loading u-boot, mmc/sd-based environment saves in u-boot will get us away from the uEnv.txt/boot.scr junk, we can move MLO to the boot sector, and then we can have cards with only a single partition.  I can appreciate the "if it ain't broke, don't fix it" point of view, but I really feel like the FAT support in the ROM/x-loader/u-boot is pretty rotten.  Am I the only one to experience that?

Loïc Minier

unread,
Mar 13, 2011, 7:42:20 AM3/13/11
to beagl...@googlegroups.com
On Fri, Mar 11, 2011, Jason Kridner wrote:
> I really feel like the FAT support
> in the ROM/x-loader/u-boot is pretty rotten. Am I the only one to
> experience that?

I wonder how solid u-boot's ext code is in the face of unclean
shutdowns. FAT is a pretty dumb fs which makes it pretty unlikely to
get corrupt; extN with journals seems significantly more complex for a
bootloader to deal with.

--
Lo�c Minier

Jason Kridner

unread,
Mar 13, 2011, 6:44:14 PM3/13/11
to beagl...@googlegroups.com

It is because FAT is so dumb that it is *easy* to become corrupt.
While the bootloader may not have all of the smarts for dealing with
the journals, the fact that you can recover a partially damaged file
system using them utilizing another booting system is a significant
improvement over the behavior of FAT. No modern operating system,
Linux, Windows, Mac OS X or otherwise is even capable of running full
featured on a FAT file system.

I guess I just don't see why an extN partition is any more at risk
than a FAT partition--certainly not the fact that it is dumb.

My experience has been that u-boot has occasionally been confused with
modifications to the FAT file system. I haven't experienced that with
ext2, but it is indeed quite probable that the only reason I haven't
seen it is because I've spent less time using ext2 along with u-boot.
This said, is there a quantifiable method for us to establish u-boot's
robustness of handling either file system type?

Vladimir Pantelic

unread,
Mar 14, 2011, 4:04:30 AM3/14/11
to beagl...@googlegroups.com
Jason Kridner wrote:
>
> My experience has been that u-boot has occasionally been confused with
> modifications to the FAT file system. I haven't experienced that with

that should be fixed. FAT is not too hard to implement and get right.

Jason Kridner

unread,
Mar 16, 2011, 4:15:54 PM3/16/11
to beagl...@googlegroups.com
Can you try turning back on PREEMPT and in drivers/mmc/host/omap_hsmmc.c, search for set_data_timeout and set dto = 14 just before the reg &= ~DTO_MASK;.  I believe this will set the timeout to the worst case every time.  One of the smarter Linux hacks says this has been working for him for a while as a work-around.

Jason Kridner

unread,
Mar 16, 2011, 6:17:00 PM3/16/11
to beagl...@googlegroups.com, ger...@beaglebord.org
On Thursday, March 10, 2011 10:35:51 AM UTC-5, Koen Kooi wrote:
Hi,

With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:

http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz

Installing it is just a matter of 'zcat  validation-GNOME-try5-image-beagleboard-sd-4GiB.img.gz > /dev/sdX', where 'X' is the drive letter of your SD card.

regards,

Koen

Gerald needed an image that worked with the on-board camera and the code in the 2.6.37 kernel still isn't quite stable, so Koen produced another image for us:

http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-2.6.32-try1-image-beagleboard-sd-4GiB.img.gz

The kernel patched for xM rev C (not part of the above image):

http://beagleboard-validation.s3.amazonaws.com/sd/uImage-2.6.32-r100+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155-beagleboard.bin  <-- not sure why I couldn't wget this link even with the + escaped
http://beagleboard-validation.s3.amazonaws.com/sd/2.6.32-r100/uImage-2.6.32-r100-beagleboard.bin  <-- this is the same file renamed

On this one,  you are going to need a Linux machine to download the above kernel and put it in /boot on the ext2 partition if you were using an xM-C board, because the Ethernet wouldn't come up.  If you use an xM-B board, you should be able to wget it without any problem.

Some quick things I've noted:
* It uses an older (slower) u-boot with a lot of the old issues that were fixed, including ext2load support.
* My display doesn't look right.
* EHCI hub still doesn't power up.

I need to leave to catch a plane and will look again at it on Friday.

Regards,
Jason

Jason Kridner

unread,
Mar 16, 2011, 6:17:06 PM3/16/11
to beagl...@googlegroups.com, ger...@beaglebord.org

Jason Kridner

unread,
Mar 16, 2011, 8:07:50 PM3/16/11
to beagl...@googlegroups.com, ger...@beaglebord.org

oh, and the ehci not working is probably my fault.

--

Robert Nelson

unread,
Mar 16, 2011, 8:09:26 PM3/16/11
to beagl...@googlegroups.com
>>
>> # CONFIG_PREEMPT_RCU is not set
>> CONFIG_PREEMPT_NONE=y
>> # CONFIG_PREEMPT_VOLUNTARY is not set
>> # CONFIG_PREEMPT is not set
>
> Can you try turning back on PREEMPT and in drivers/mmc/host/omap_hsmmc.c,
> search for set_data_timeout and set dto = 14 just before the reg &=
> ~DTO_MASK;.  I believe this will set the timeout to the worst case every
> time.  One of the smarter Linux hacks says this has been working for him for
> a while as a work-around.

Hey Jason,

Here's my results.. some might say it's rigged, since i used the most
"crappy/consistently/bad" mmc -110 card..

It's a PNY Optima SDHC 4GB mmc in my C4 beagle.. on 2.6.37...


No Patch, with preempt:
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_PREEMPT_NONE is not set


# CONFIG_PREEMPT_VOLUNTARY is not set

CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TRACER is not set

[ 7.219329] mmc0: error -110 whilst initialising SD card

With Patch and preempt:
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0dfb860..eadf150 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1424,6 +1424,8 @@ static void set_data_timeout(struct omap_hsmmc_host *host,
dto = 14;
}

+ dto = 14;
+
reg &= ~DTO_MASK;
reg |= dto << DTO_SHIFT;
OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);

CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_PREEMPT_NONE is not set


# CONFIG_PREEMPT_VOLUNTARY is not set

CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TRACER is not set

[ 7.242584] mmc0: error -110 whilst initialising SD card

No Patch, no preempt..

# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

[ 5.118316] mmc0: new high speed SDHC card at address 1234
[ 5.226989] mmcblk0: mmc0:1234 SA04G 3.68 GiB
[ 5.319000] mmcblk0: p1 p2

Dave N6NZ

unread,
Mar 16, 2011, 10:20:27 PM3/16/11
to beagl...@googlegroups.com

Hmmm... isn't that interesting. Maybe we are closing in on it.
According to what I've read, CONFIG_PREEMPT=Y means the
kernel can be preempted unless it is holding a lock. So might
this be a missing lock in the mmc driver someplace?

Also according to what I've read,
CONFIG_PREEMPT_VOLUNTARILY=Y
allows the kernel to voluntarily be preempted, but yields lower
latency than CONFIG_PREEMPT_NONE=Y.

So, as I understand it, this would be a valid configuration:


# CONFIG_PREEMPT_RCU is not set

# CONFIG_PREEMPT_NONE is not set

CONFIG_PREEMPT_VOLUNTARY=Y


# CONFIG_PREEMPT is not set

which might be worthwhile testing.

OTOH, maybe CONFIG_PREEMPT_RCU is the the conflict here.
So...


# CONFIG_PREEMPT_RCU is not set

# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set

CONFIG_PREEMPT=Y
...should isolate RCU, IIUC.

Anyway... those are my random, non-expert thoughts for the day.
No charge.

-dave

>
> Regards,
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

Jim Norton

unread,
Mar 22, 2011, 8:24:02 PM3/22/11
to beagl...@googlegroups.com
Just wanted to let you all know that I've gotten SPIDEV working on the
BeagleBoard-xM and the TinCanTools Trainer board. I said that I would
update you all when I got things working.

Thanks to the many helpful hints everybody. If you are interested in
what I did you can visit my blog at: http://beagleboardxm.org/blog/

Thanks again for all of the help!

Regards,
Jim


----- End message from jimn...@jimnorton.org -----

lchile

unread,
Mar 23, 2011, 4:14:58 AM3/23/11
to Beagle Board
This is setup OK for me (under windows using 7Zip and Win32 Disk
Imager). However there is no option to shutdown from the Gnome menu,
and upon install Firefox doesn't render text either within the menus
or in the browser window.

Is it possible in the future Angstrom demo images can be made to
automatically resize the install to use the whole of the SD Card
irrespective of size, like the Ubuntu install?

Thanks!

Jason Kridner

unread,
Mar 25, 2011, 4:42:16 PM3/25/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile

Koen shared a new SD card image (uninitialized) that I mirrored on
beagleboard.org [1].

I noticed that when I had the TinCanTools Trainer-xM plugged in, my
Ethernet didn't work. I'll get back to that issue with this software
image later.

I got a related question from Mark about how to perform the partition
resizing, so I figured I'd address that here. I don't believe you'd
be able to resize a mounted partition and that this operation would
require another file system to mount. Because this image does not
have the ramdisk, I downloaded the one used being shipped with the xM
boards today [2].

===============================
root@beagleboard:~# wget
http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/ramdisk.gz
Connecting to beagleboard-validation.s3.amazonaws.com (72.21.214.39:80)
ramdisk.gz 100% |*******************************| 19492k 00:00:00 ETA
root@beagleboard:~# cp ramdisk.gz /media/mmcblk0p1/
root@beagleboard:~# shutdown -r now
===============================

I halted the board during reboot and did:

===============================
OMAP3 beagleboard.org # mmc rescan 0
OMAP3 beagleboard.org # run loaduimage
Loading file "/boot/uImage" from mmc device 0:2 (xxa2)
3194256 bytes read
OMAP3 beagleboard.org # run loadramdisk
reading ramdisk.gz

19960110 bytes read
OMAP3 beagleboard.org # run ramboot
===============================

I allowed it to boot and did:

===============================
root@beagleboard:~# umount /dev/mmcblk0p1
root@beagleboard:~# umount /dev/mmcblk0p2
root@beagleboard:~# fdisk /dev/mmcblk0

Command (m for help): p

Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes
255 heads, 63 sectors/track, 482 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 1 15 120456 c W95 FAT32 (LBA)
/dev/mmcblk0p2 16 444 3445942+ 83 Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (16-482, default 16):
Using default value 16
Last cylinder, +cylinders or +size{K,M,G} (16-482, default 482):
Using default value 482

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
root@beagleboard:~# umount /dev/mmcblk0p2
root@beagleboard:~# resize2fs /dev/mmcblk0p2
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/mmcblk0p2 to 937794 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 937794 blocks long.

root@beagleboard:~# shutdown -r now
===============================

I then waited for the reboot. That was all there was to it.

Going the other way would require performing the resize operation
first and specifying the size.

Anyone care to automate this and submit this to Angstrom?


[1] http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-modules-try2-image-beagleboard-sd-4GiB.img.gz
[2] http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/ramdisk.gz

Jason Kridner

unread,
Mar 30, 2011, 9:25:33 AM3/30/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile, ko...@beagleboard.org, ger...@beagleboard.org

[1] http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-modules-try2-image-beagleboard-sd-4GiB.img.gz

Koen,
 
Per off-line discussions, thanks for updating the image to include
* vim
* 3d demos

I've mirrored the latest image at: http://www.beagleboard.org/~share/validation-GNOME-I-lost-count-image-beagleboard-sd-4GiB.img.gz

The follow issues have been noted by people trying it out:
1) u-boot reports "Beagle unknown 02".  I can release a patch today to fix this if no one else says they want to do it.  (probably need to fix ahead of release, but I could live with the questions)

2) u-boot prints a message about not finding a uEnv.txt.  There doesn't need to be one, but I will recommend to CircuitCo that they put one on the image they ship.  Do we want hd720 or 640x480?  I'd lean toward hd720 and just hold the USER button down to get 640x480, because that would cause user.txt to be looked for instead of uEnv.txt.  My settings at https://groups.google.com/d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J did prevent the screen from blanking for a day, but something happened and now it has started going blank again. (no need to fix ahead of release)

3) Booting the kernel I get an error about libnl.so.1 not found.  Can you say why this is? (only need to fix ahead of release if it is symptomatic of a larger problem)

4) The 3D demos work, but the texture streaming demo does not.
Running it from the command line produces the error:

root@beagleboard:/# /usr/bin/gles2_bc_webcam-x11
INFO: current input is Camera 1
ERROR: BCIOREQ_BUFFERS failed
done
root@beagleboard:/#

Steve guesses this means the application cannot get buffers from the bufferclass_ti driver.  Do you have any ideas here? (probably need to fix ahead of release to show the camera working)

5) I need to change the size of memory to test passed to testmem.  (might not need to fix before release)

6) The editbootscr/edituserscr utilities are now obsolete.  The example boot scripts need to be replaced with example environment variable text files.  (might not need to fix before release)


All,

Can you please try this image out?  This one looks very close to what will ship.  I'm interested if anyone misses the Qt or GStreamer labs, any browsers or media players, anything?

Regards,
Jason

Koen Kooi

unread,
Mar 30, 2011, 9:39:24 AM3/30/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile, ger...@beagleboard.org

Op 30 mrt 2011, om 15:25 heeft Jason Kridner het volgende geschreven:

> [1] http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-modules-try2-image-beagleboard-sd-4GiB.img.gz
>
> Koen,
>
> Per off-line discussions, thanks for updating the image to include
> * vim
> * 3d demos
>
> I've mirrored the latest image at: http://www.beagleboard.org/~share/validation-GNOME-I-lost-count-image-beagleboard-sd-4GiB.img.gz
>
> The follow issues have been noted by people trying it out:
> 1) u-boot reports "Beagle unknown 02". I can release a patch today to fix this if no one else says they want to do it. (probably need to fix ahead of release, but I could live with the questions)
>
> 2) u-boot prints a message about not finding a uEnv.txt. There doesn't need to be one, but I will recommend to CircuitCo that they put one on the image they ship. Do we want hd720 or 640x480? I'd lean toward hd720 and just hold the USER button down to get 640x480, because that would cause user.txt to be looked for instead of uEnv.txt. My settings at https://groups.google.com/d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J did prevent the screen from blanking for a day, but something happened and now it has started going blank again. (no need to fix ahead of release)
>
> 3) Booting the kernel I get an error about libnl.so.1 not found. Can you say why this is? (only need to fix ahead of release if it is symptomatic of a larger problem)

Not sure about that one, I suspect it's a dlopen() kind of error. Any way to find out which app/lib is giving that error?

> 4) The 3D demos work, but the texture streaming demo does not.
> Running it from the command line produces the error:
>
> root@beagleboard:/# /usr/bin/gles2_bc_webcam-x11
> INFO: current input is Camera 1
> ERROR: BCIOREQ_BUFFERS failed
> done
> root@beagleboard:/#
>
> Steve guesses this means the application cannot get buffers from the bufferclass_ti driver. Do you have any ideas here? (probably need to fix ahead of release to show the camera working)

This probably needs some spare VRAM to work

something like:

setenv vram '16M'
setenv dvimode 'hd720 omapfb.vram=0:8M,1:4M,2:4M'


regards,

Koen

Jason Kridner

unread,
Mar 31, 2011, 8:00:36 AM3/31/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile, ger...@beagleboard.org, ko...@beagleboard.org
On Wednesday, March 30, 2011 9:39:24 AM UTC-4, Koen Kooi wrote:

Op 30 mrt 2011, om 15:25 heeft Jason Kridner het volgende geschreven:

> [1] http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-modules-try2-image-beagleboard-sd-4GiB.img.gz
>
> Koen,
>  
> Per off-line discussions, thanks for updating the image to include
> * vim
> * 3d demos
>
> I've mirrored the latest image at: http://www.beagleboard.org/~share/validation-GNOME-I-lost-count-image-beagleboard-sd-4GiB.img.gz
>
> The follow issues have been noted by people trying it out:
> 1) u-boot reports "Beagle unknown 02".  I can release a patch today to fix this if no one else says they want to do it.  (probably need to fix ahead of release, but I could live with the questions)

I submitted a patch to u-boot for this, but haven't pushed it to Angstrom yet.  I'll try to do that shortly after I finish my checkout.
 

>
> 2) u-boot prints a message about not finding a uEnv.txt.  There doesn't need to be one, but I will recommend to CircuitCo that they put one on the image they ship.  Do we want hd720 or 640x480?  I'd lean toward hd720 and just hold the USER button down to get 640x480, because that would cause user.txt to be looked for instead of uEnv.txt.  My settings at https://groups.google.com/d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J did prevent the screen from blanking for a day, but something happened and now it has started going blank again. (no need to fix ahead of release)
>
> 3) Booting the kernel I get an error about libnl.so.1 not found.  Can you say why this is? (only need to fix ahead of release if it is symptomatic of a larger problem)

Not sure about that one, I suspect it's a dlopen() kind of error. Any way to find out which app/lib is giving that error?

It is NetworkManager.
 

> 4) The 3D demos work, but the texture streaming demo does not.
> Running it from the command line produces the error:
>
> root@beagleboard:/# /usr/bin/gles2_bc_webcam-x11
> INFO: current input is Camera 1
> ERROR: BCIOREQ_BUFFERS failed
> done
> root@beagleboard:/#
>
> Steve guesses this means the application cannot get buffers from the bufferclass_ti driver.  Do you have any ideas here? (probably need to fix ahead of release to show the camera working)

This probably needs some spare VRAM to work

something like:

setenv vram '16M'
setenv dvimode 'hd720 omapfb.vram=0:8M,1:4M,2:4M'

I have in /proc/cmdline: console=ttyS2,115200n8 console=tty0 consoleblank=0 mpurate=auto buddy=none camera=lbcm3m1 vram=16M omapfb.mode=dvi:hd720 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait

The texture streaming demo app still fails as above.

The "consoleblank=0" setting also doesn't seem to be working for me as when the GUI comes up, the screen goes blank.  It worked for a day for me, so I'm confused what that was about (perhaps some events were keeping the monitor awake?)  I'm not sure if Gerald needs it, but I've tried adjusting the power management settings in GNOME to see if that makes a difference for me.
 
> 5) I need to change the size of memory to test passed to testmem.  (might not need to fix before release)

Based on the xM free memory, I should probably change this from 360M to 330M, or perhaps 320M.
 

>
> 6) The editbootscr/edituserscr utilities are now obsolete.  The example boot scripts need to be replaced with example environment variable text files.  (might not need to fix before release)
>
>
> All,
>
> Can you please try this image out?  This one looks very close to what will ship.  I'm interested if anyone misses the Qt or GStreamer labs, any browsers or media players, anything?
>
> Regards,
> Jason


Other issues I've found:
6) In u-boot, if you set the i2c device to something other than 0, you can get an error in the mmc command:

OMAP3 beagleboard.org # mmc rescan 0
I2C read: I/O error
I2C read: I/O error

I don't think this is worth fixing prior to any release, but it is something for me to fix.

7) The u-boot MUSB serial emulator isn't working.  (don't fix, but I might consider pulling in the DFU patch as a stretch goal)

8) testcamera screws up the GNOME session as well as the serial console session.  If we are booting into X11, it probably makes sense to switch to gnome-mplayer.  If the texture streaming demo was working, I'd just switch testcamera to use it.  Since testcamera/mplayer does show that the camera input is working, I'd put this in the category of not required to fix before shipping, but if there is another revision, include gnome-mplayer.  I did confirm that "gnome-mplayer tv:///" works.

9) The g_ether instructions are working again, so I'm pretty happy about that, but the kernel still crashes when you power-up with USB connected.  Can we ship with g_ether installed by default and request that people replace the kernel if the want *not* to have g_ether, rather than the other way around?

10) "opkg install kernel-2.6.37" doesn't work.  It seems to be on a different feed.  This makes installing the newer kernel for using the BeagleBoardToys Wi-Fi adapter pretty complicated.  I did:

echo "src/gz beagleboard-next http://www.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/machine/beagleboard" >> /etc/opkg/beagleboard-next-feed.conf
opkg update
opkg install kernel-2.6.37
opkg install kernel-image-2.6.37
opkg install kernel-modules
ln -sf /boot/uImage-2.6.37 /boot/uImage
vim /media/mmcblk0p1/UENV.TXT # update console as appropriate
vim /etc/inittab # update console as appropriate
opkg install iw
vim /etc/network/interfaces # update wlan0 as appropriate
shutdown -r now

I don't know what to do next as 'modprobe wl1271_sdio' or 'modprobe wl1271_spi' both give unknown symbol errors and I don't see another wl1271 .ko file to load.  I was able to figure that some modules didn't get upgraded, but I'm still working through the details.

(I believe Gerald is requiring a documented upgrade process to a kernel that works with the wifi board.  Can you document the process?)

11) The MLO and u-boot files in /boot are old.  Why?  The ownership is also odd with it being set to www-data.  (Not critical, but nice to fix.)

12) http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/u-boot/u-boot_git.bb shows ttyO2 should be the default, but that isn't the version being built.  That is quite confusing. I am just noticing we are using 2011.03-maintenance for this.  Looking at the logs, it seems you are aligning the key recipes quickly on this.  I guess for those looking to pick something up and run with it, being off of that branch is indeed better. (nothing to fix)

Koen Kooi

unread,
Mar 31, 2011, 8:34:35 AM3/31/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile, ger...@beagleboard.org

Op 31 mrt 2011, om 14:00 heeft Jason Kridner het volgende geschreven:

> 10) "opkg install kernel-2.6.37" doesn't work. It seems to be on a different feed. This makes installing the newer kernel for using the BeagleBoardToys Wi-Fi adapter pretty complicated. I did:
>
> echo "src/gz beagleboard-next http://www.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/machine/beagleboard" >> /etc/opkg/beagleboard-next-feed.conf
> opkg update
> opkg install kernel-2.6.37
> opkg install kernel-image-2.6.37
> opkg install kernel-modules
> ln -sf /boot/uImage-2.6.37 /boot/uImage
> vim /media/mmcblk0p1/UENV.TXT # update console as appropriate
> vim /etc/inittab # update console as appropriate
> opkg install iw
> vim /etc/network/interfaces # update wlan0 as appropriate
> shutdown -r now

Don't mix and match feeds. The glibc 2.9 -> eglibc 2.11 + gcc 4.3 -> gcc 4.5 is just too big to be expected to "just work".

> I don't know what to do next as 'modprobe wl1271_sdio' or 'modprobe wl1271_spi' both give unknown symbol errors and I don't see another wl1271 .ko file to load.

It's called wl12xx in newer kernels.

Jim Norton

unread,
Mar 31, 2011, 9:17:29 AM3/31/11
to beagl...@googlegroups.com
Hi Koen,

Just wanted to thank you for being so helpful on this list. I've had
my BeagleBoard-xM for less than a month and this list and your
comments have been extremely helpful. I really appreciate it.

Cheers,
Jim
beagleboardxm.org

----- Message from ko...@beagleboard.org ---------

Date: Thu, 31 Mar 2011 14:34:35 +0200

Subject: Re: [beagleboard] Re: New SD card image to test
To: beagl...@googlegroups.com
Cc: "Yoder, Mark A" <yo...@rose-hulman.edu>, lchile
<beaufo...@gmail.com>, ger...@beagleboard.org

Jason Kridner

unread,
Mar 31, 2011, 9:37:49 AM3/31/11
to beagl...@googlegroups.com, Koen Kooi, Yoder, Mark A, lchile, ger...@beagleboard.org
On Thu, Mar 31, 2011 at 8:34 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>
> Op 31 mrt 2011, om 14:00 heeft Jason Kridner het volgende geschreven:
>
>> 10) "opkg install kernel-2.6.37" doesn't work.  It seems to be on a different feed.  This makes installing the newer kernel for using the BeagleBoardToys Wi-Fi adapter pretty complicated.  I did:
>>
>> echo "src/gz beagleboard-next http://www.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/machine/beagleboard" >> /etc/opkg/beagleboard-next-feed.conf
>> opkg update
>> opkg install kernel-2.6.37
>> opkg install kernel-image-2.6.37
>> opkg install kernel-modules
>> ln -sf /boot/uImage-2.6.37 /boot/uImage
>> vim /media/mmcblk0p1/UENV.TXT # update console as appropriate
>> vim /etc/inittab # update console as appropriate
>> opkg install iw
>> vim /etc/network/interfaces # update wlan0 as appropriate
>> shutdown -r now
>
> Don't mix and match feeds. The glibc 2.9 -> eglibc 2.11 + gcc 4.3 -> gcc 4.5 is just too big to be expected to "just work".

Is there a reason 2.6.37 isn't being built on the other feed? Is
there a way for me to add it?

What is the mechanism for testing the BeagleBoardToys wi-fi module?

Koen Kooi

unread,
Mar 31, 2011, 10:41:55 AM3/31/11
to Jason Kridner, beagl...@googlegroups.com, Yoder, Mark A, lchile, ger...@beagleboard.org

Op 31 mrt 2011, om 15:37 heeft Jason Kridner het volgende geschreven:

> On Thu, Mar 31, 2011 at 8:34 AM, Koen Kooi <ko...@beagleboard.org> wrote:
>>
>> Op 31 mrt 2011, om 14:00 heeft Jason Kridner het volgende geschreven:
>>
>>> 10) "opkg install kernel-2.6.37" doesn't work. It seems to be on a different feed. This makes installing the newer kernel for using the BeagleBoardToys Wi-Fi adapter pretty complicated. I did:
>>>
>>> echo "src/gz beagleboard-next http://www.angstrom-distribution.org/feeds/next/ipk/eglibc/armv7a/machine/beagleboard" >> /etc/opkg/beagleboard-next-feed.conf
>>> opkg update
>>> opkg install kernel-2.6.37
>>> opkg install kernel-image-2.6.37
>>> opkg install kernel-modules
>>> ln -sf /boot/uImage-2.6.37 /boot/uImage
>>> vim /media/mmcblk0p1/UENV.TXT # update console as appropriate
>>> vim /etc/inittab # update console as appropriate
>>> opkg install iw
>>> vim /etc/network/interfaces # update wlan0 as appropriate
>>> shutdown -r now
>>
>> Don't mix and match feeds. The glibc 2.9 -> eglibc 2.11 + gcc 4.3 -> gcc 4.5 is just too big to be expected to "just work".
>
> Is there a reason 2.6.37 isn't being built on the other feed?

It's not supported in that angstrom release

> Is
> there a way for me to add it?

Practically, no, see above.

> What is the mechanism for testing the BeagleBoardToys wi-fi module?

Use a different angstrom release.

lchile

unread,
Apr 3, 2011, 11:33:09 AM4/3/11
to Beagle Board
Thank you - this version is great, sound is working reliably, and most
smooth operation of all Angstrom installs I have so far experienced:

http://www.google.com/url?sa=D&q=http://beagleboard-validation.s3.amazonaws.com/sd/validation-GNOME-2.6.32-try1-image-beagleboard-sd-4GiB.img.gz

Jason Kridner

unread,
Apr 3, 2011, 4:47:04 PM4/3/11
to beagl...@googlegroups.com, lchile

Did you try any of the newer images on this thread?

lchile

unread,
Apr 4, 2011, 3:17:24 AM4/4/11
to Beagle Board
Sorry, no, unfortunately I won't have another chance until the end of
the week now.

On Apr 3, 9:47 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> On Sun, Apr 3, 2011 at 11:33 AM, lchile <beaufortsc...@gmail.com> wrote:
> > Thank you - this version is great, sound is working reliably, and most
> > smooth operation of all Angstrom installs I have so far experienced:
>
> >http://www.google.com/url?sa=D&q=http://beagleboard-validation.s3.ama...

Koen Kooi

unread,
Apr 5, 2011, 6:43:23 AM4/5/11
to beagl...@googlegroups.com, Yoder, Mark A, lchile, ger...@beagleboard.org

Op 30 mrt 2011, om 15:25 heeft Jason Kridner het volgende geschreven:

>
> 3) Booting the kernel I get an error about libnl.so.1 not found. Can you say why this is? (only need to fix ahead of release if it is symptomatic of a larger problem)

opkg update && opkg upgrade

lchile

unread,
Apr 9, 2011, 12:45:58 PM4/9/11
to Beagle Board
Tried out this image, pretty good - the uEnv.txt functionality is
useful, however what is the syntax for that file, the following copied
from the boot.scr of another installation doesn't seem to work -
returns 640x480 default:

setenv vram '16M'
setenv dvimode '1024x768MR-16@60 omapfb.vram=0:8M,1:4M,2:4M'

I wanted to change to these settings, as performance of Gnome-Mplayer
playing MP4 files was significantly better in the image Koen produced
for Gerald that you mentioned further up:http://beagleboard-
validation.s3.amazonaws.com/sd/validation-GNOME-2.6.32-try1-image-
beagleboard-sd-4GiB.img.gz

In Gnome-Mplayer MP4 playback in your latest image was a lot jerkier,
losing frames and mouse movement impacted on this heavily too. Will an
amended uEnv.txt make the difference?

In general though in my opinion, I would make these points,
particularly if this image is to be targeted at people new to the
platform, maybe they can't be resolved in this iteration but would
help in the future:

psplash-angstrom should be installed as default to give graphical
feedback of the boot process. Is there any way to give on-screen
indicators of the duration of first boot after setting up the sd card,
as it taking 20+ minutes might give new people concerns?

Why no shutdown or reboot options from the Gnome menu anymore? Do
appreciate that setting up desktop launchers to do this is trivial
though.

Preferences>Sound reuslts in 'waiting for sound system to respond'

Places>Home Folder results in "Could not open location 'file:///home/
root' No application is registered as handling this file"

The default settings of the Gnome menu now highlights the text the
mouse moves over in white, no very readable - didn't do this before.

In terms of applications installed as default the only one I would
question is why have movie player instead of Gnome-Mplayer - is this
not more optimized for the platform? It certainly seems to handle more
formats more easily. I know mplayer is installed as default, but
reckon Gnome-Mplayer is also good for demonstration.

Please also can you detail all the improvements of this version over
previous, so I can test for them.

Really impressed how Angstrom has come along in recent weeks, thanks
very much!

On Mar 30, 2:25 pm, Jason Kridner <jkrid...@gmail.com> wrote:
> > [1]
> >http://www.beagleboard.org/~share/validation-GNOME-2.6.32-all-kernel-...
>
> Koen,
>
> Per off-line discussions, thanks for updating the image to include
> * vim
> * 3d demos
>
> I've mirrored the latest image at:http://www.beagleboard.org/~share/validation-GNOME-I-lost-count-image...
>
> The follow issues have been noted by people trying it out:
> 1) u-boot reports "Beagle unknown 02".  I can release a patch today to fix
> this if no one else says they want to do it.  (probably need to fix ahead of
> release, but I could live with the questions)
>
> 2) u-boot prints a message about not finding a uEnv.txt.  There doesn't need
> to be one, but I will recommend to CircuitCo that they put one on the image
> they ship.  Do we want hd720 or 640x480?  I'd lean toward hd720 and just
> hold the USER button down to get 640x480, because that would cause user.txt
> to be looked for instead of uEnv.txt.  My settings athttps://groups.google.com/d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J<../../../d/msg/beagleboard/0cthQxYZ344/_1KoP0eRgd4J>did prevent the screen from blanking for a day, but something happened and

lchile

unread,
Apr 9, 2011, 12:47:14 PM4/9/11
to Beagle Board
PS - I tested this on a Beagleboard XM Rev A2 btw.

Jason Kridner

unread,
Apr 10, 2011, 11:43:39 AM4/10/11
to beagl...@googlegroups.com, lchile
On Sat, Apr 9, 2011 at 12:45 PM, lchile <beaufo...@gmail.com> wrote:
> Tried out this image, pretty good - the uEnv.txt functionality is
> useful, however what is the syntax for that file, the following copied
> from the boot.scr of another installation doesn't seem to work -
> returns 640x480 default:
>
> setenv vram '16M'
> setenv dvimode '1024x768MR-16@60 omapfb.vram=0:8M,1:4M,2:4M'

It is covered on another thread on this mailing list, so please
attempt a search. So that the record is also here:

vram=16M
dvimode="1024x768MR-16@60 omapfb.vram=0:8M,1:4M,2:4M"

http://patchwork.ozlabs.org/patch/85292/

lchile

unread,
Apr 11, 2011, 3:25:33 AM4/11/11
to Beagle Board
Thanks Jason, unfortunately this change doesn't help with the issues
with Gnome-Mplayer detailed that aren't present in the previous
version I detailed.

On Apr 10, 4:43 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
Reply all
Reply to author
Forward
0 new messages