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
Any significant changes in revision C? Does it require changes to
x-load, u-boot, or kernel?
Steve
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
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
so u-boot actually now "correctly" reads the uImage file off the ext3 partition?
Regards,
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.
And wikis are out of date by definition
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)?so u-boot actually now "correctly" reads the uImage file off the ext3 partition?
It does over here and at Jasons as well 
It even follows symlinks!
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'
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.
Fails on rev C3
To be clear, original BeagleBoard (not xM) rev C3
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.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 (443 Bytes)
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 jkridner@beagleboard.org ---------
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
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..)
Regards,
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 cardThis 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.)
-dave
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 cardThis 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...
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 cardThis 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
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
Regards,
Angstrom supports them all
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 koen@beagleboard.org ---------
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.