New SD card image to test
Koen Kooi
With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
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
> 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
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
>
> 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
so u-boot actually now "correctly" reads the uImage file off the ext3 partition?
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
Koen Kooi
Package upgrades work and the kernel matches the fs.
And wikis are out of date by definition
Koen Kooi
It does over here and at Jasons as well :) It even follows symlinks!
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>
Gary Thomas
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
> 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
> 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?
Jim Norton
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
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
>
> 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
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
>
> 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
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
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
Jim Norton
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
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
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
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.
Loïc Minier
> 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
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
>
> 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
Jason Kridner
Hi,With the imminent release of the BeagleBoard xM revision C we needed to do a new SD image. RC5 can be downloaded here:
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
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
Jason Kridner
oh, and the ehci not working is probably my fault.
--
Robert Nelson
>> # 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
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
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
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
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
* 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
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
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'
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:
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
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
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
From: Koen Kooi <ko...@beagleboard.org>
Reply-To: beagl...@googlegroups.com
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
>
> 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
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
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
Did you try any of the newer images on this thread?
lchile
the week now.
On Apr 3, 9:47 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> > Thank you - this version is great, sound is working reliably, and most
> > smooth operation of all Angstrom installs I have so far experienced:
>
Koen Kooi
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
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
>
> 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
lchile
Jason Kridner
> 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
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: