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