Beagle actions for Rev C validation software image

Based on our meeting this morning, here are the actions I took down for finalizing our Rev C validation image this week. All validation code and processes will go on http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation.

Jason:
* Provide list of commits to pull for u-boot. (This will build the recovery u-boot that ignores the environment variables on the flash, not just the one that will go into the flash.)
* Clone Linux kernel w/ OE patches to gitorious in case beagleboard.org crashes.
* Provide new ramdisk image based on the Arago overlay of Angstrom that is smaller and will boot faster. (Steve will test.)

Khasim:
* Provide source links to svideo and evtest utilities on the wiki page. (Jason may try to incorporate into the ramdisk image script build so they aren't hacked-in.)
* Use another splash screen that works with Pico Projector. (Try the old one, but check with Koen why the Angstrom demo won't boot with it.)
* Provide patch for I2C bus switch fix patch. (Include Beagle mailing list)
* Work on reading the ADC for active power measurement.

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down for
finalizing our Rev C validation image this week. All validation code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the recovery
u-boot that ignores the environment variables on the flash, not just the one
that will go into the flash.)
* Clone Linux kernel w/ OE patches to gitorious in case beagleboard.org
crashes.
* Provide new ramdisk image based on the Arago overlay of Angstrom that is
smaller and will boot faster. (Steve will test.)

Hopefully the mailing list won't find this "down-in-the-guts" work to
be too much noise. I'm hopeful that by being open for the Rev C
release we can generate better support collateral out of the
community.

I haven't had a chance to test this yet.

I've generated a new minimal file system build at:
http://www.beagleboard.org/~arago/arago-deploy/images/beagleboard/arago-base-image-beagleboard.ext2.gz

To build this, I used tag "validation-20090127":
http://www.beagleboard.org/gitweb/?p=arago.git

For mplayer and other utilities, look at:
http://www.beagleboard.org/~arago/arago-deploy/ipk/armv5te/

To build these, I used tag "validation-20090127":
http://www.beagleboard.org/gitweb/?p=arago-oe.git

Khasim,

See below...

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down for
finalizing our Rev C validation image this week. All validation code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the recovery
u-boot that ignores the environment variables on the flash, not just the one
that will go into the flash.)

I have applied my patches against the head of your tree on a branch
called 'for-khasim':
http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/logs/for-khasim

This is built (and untested) at:
http://www.beagleboard.org/~arago/u-boot.bin
http://www.beagleboard.org/~arago/u-boot-f.bin

* Clone Linux kernel w/ OE patches to gitorious in case beagleboard.org
crashes.

It will go here when Gitorious I finish uploading it (will apply a
validation-20090127 tag):
http://gitorious.org/projects/beagleboard-diagnostic-kernel

Jason Kridner wrote:

Khasim,

See below...

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down for
finalizing our Rev C validation image this week. All validation code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the recovery
u-boot that ignores the environment variables on the flash, not just the one
that will go into the flash.)

I have applied my patches against the head of your tree on a branch
called 'for-khasim':
http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/logs/for-khasim

Any plans to fix dss_init() in

http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/blobs/for-khasim/board/omap3/beagle/beagle.c

?

Doing stuff like *((uint *) for register access could be broken? Using
potentially broken code for validation sounds strange.

Use readx/writex?

Fix hard coded 0x48310034 = 0xfefffedf; stuff?

Dirk

Jason Kridner wrote:

Khasim,

See below...

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down for
finalizing our Rev C validation image this week. All validation code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the recovery
u-boot that ignores the environment variables on the flash, not just the one
that will go into the flash.)

I have applied my patches against the head of your tree on a branch
called 'for-khasim':
http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/logs/for-khasim

Any plans to fix dss_init() in

http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/blobs/for-khasim/board/omap3/beagle/beagle.c

?

Doing stuff like *((uint *) for register access could be broken? Using
potentially broken code for validation sounds strange.

Use readx/writex?

Fix hard coded 0x48310034 = 0xfefffedf; stuff?

Dirk,

Can you point to a link/example with the proper format? I assume this
is for the clock init accesses, correct?

Also, I'd really welcome a patch that works on HDTVs and the Pico
projector. The old splash screen worked with the Pico projector and
many HDTVs. The current dss_init() doesn't work with any display that
I have, but it must be working with some DVI-D monitors.

All of the DVI-D monitors and PICO that I have tried do not work as well.

Gerald

Op 27 jan 2009 om 16:08 heeft Jason Kridner <jkridner@beagleboard.org>
het volgende geschreven:\

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down
for
finalizing our Rev C validation image this week. All validation
code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the
recovery
u-boot that ignores the environment variables on the flash, not
just the one
that will go into the flash.)
* Clone Linux kernel w/ OE patches to gitorious in case
beagleboard.org
crashes.
* Provide new ramdisk image based on the Arago overlay of Angstrom
that is
smaller and will boot faster. (Steve will test.)

Hopefully the mailing list won't find this "down-in-the-guts" work to
be too much noise. I'm hopeful that by being open for the Rev C
release we can generate better support collateral out of the
community.

I haven't had a chance to test this yet.

I've generated a new minimal file system build at:
http://www.beagleboard.org/~arago/arago-deploy/images/beagleboard/arago-base-image-beagleboard.ext2.gz

To build this, I used tag "validation-20090127":
http://www.beagleboard.org/gitweb/?p=arago.git

For mplayer and other utilities, look at:
http://www.beagleboard.org/~arago/arago-deploy/ipk/armv5te/

It's a bit sad that we're going to miss out on NEON and vo_omapfb by
going armv5te :frowning:

Regards,

Koen

Koen,

See below...

het volgende geschreven:\

Steve K.,

See below...

Based on our meeting this morning, here are the actions I took down
for
finalizing our Rev C validation image this week. All validation
code and
processes will go on
Google Code Archive - Long-term storage for Google Code Project Hosting..

Jason:
* Provide list of commits to pull for u-boot. (This will build the
recovery
u-boot that ignores the environment variables on the flash, not
just the one
that will go into the flash.)
* Clone Linux kernel w/ OE patches to gitorious in case
beagleboard.org
crashes.
* Provide new ramdisk image based on the Arago overlay of Angstrom
that is
smaller and will boot faster. (Steve will test.)

Hopefully the mailing list won't find this "down-in-the-guts" work to
be too much noise. I'm hopeful that by being open for the Rev C
release we can generate better support collateral out of the
community.

I haven't had a chance to test this yet.

I've generated a new minimal file system build at:
http://www.beagleboard.org/~arago/arago-deploy/images/beagleboard/arago-base-image-beagleboard.ext2.gz

To build this, I used tag "validation-20090127":
http://www.beagleboard.org/gitweb/?p=arago.git

For mplayer and other utilities, look at:
http://www.beagleboard.org/~arago/arago-deploy/ipk/armv5te/

It's a bit sad that we're going to miss out on NEON and vo_omapfb by
going armv5te :frowning:

Koen,

I am rebuilding 'mplayer' now with 'MACHINE=beagleboard bitbake
mplayer', so that concern should go away. It shouldn't matter much
about this mplayer, since it should only be used to test the hardware.

Can you consider inclusion of:

mplayer and FFmpeg dependency changes:
http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca

automatic execution /media/mmcblk0p1/boot.sh:
http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=064597b9db33efbef17ca9193a1ba222a07cc7fd;hp=51d7a5e16071023433078839e79a7e33daddd1e1

Regards,
Jason

It's a bit sad that we're going to miss out on NEON and vo_omapfb by
going armv5te :frowning:

Koen,

I am rebuilding 'mplayer' now with 'MACHINE=beagleboard bitbake mplayer', so that concern should go away. It shouldn't matter much about this mplayer, since it should only be used to test the hardware.

Can you consider inclusion of:

mplayer and FFmpeg dependency changes:
http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca

Hmm, I like these curl-inspired *_FEATURES handlers. The only problem with those is they won't trigger automatic rebuild when the featureset in the variable changes - don't forget to run bitbake -c rebuild manually...

Adding oe-dev mailing list...

Adding oe-dev mailing list...

It's a bit sad that we're going to miss out on NEON and vo_omapfb by
going armv5te :frowning:

Koen,

I am rebuilding 'mplayer' now with 'MACHINE=beagleboard bitbake mplayer', so that concern should go away. It shouldn't matter much about this mplayer, since it should only be used to test the hardware.

Can you consider inclusion of:

mplayer and FFmpeg dependency changes:
http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca

Hmm, I like these curl-inspired *_FEATURES handlers. The only problem with those is they won't trigger automatic rebuild when the featureset in the variable changes - don't forget to run bitbake -c rebuild manually...

Can I get a few comments on [1]? I found there is also a dependency
in libtheora on x11 that doesn't seem necessary. I find this very
useful to avoid making a new recipe. Anyone have ideas to address
Denys' concern about needing to issue 'bitbake -c rebuild'?

I'm against adding such 'USE flags' to OE, they basically make QA impossible. If people want a different mplayer, they are free to make an 'mplayer-nox' or 'mplayer-nosdl' recipe to fill their needs.

regards,

Koen

Adding oe-dev mailing list...

>
>>> It's a bit sad that we're going to miss out on NEON and vo_omapfb by
>>> going armv5te :frowning:
>
>> Koen,
>
>> I am rebuilding 'mplayer' now with 'MACHINE=beagleboard bitbake mplayer',
>> so that concern should go away. It shouldn't matter much about this
>> mplayer, since it should only be used to test the hardware.
>
>> Can you consider inclusion of:
>
>> mplayer and FFmpeg dependency changes:
>> http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca
>
> Hmm, I like these curl-inspired *_FEATURES handlers. The only problem with
> those is they won't trigger automatic rebuild when the featureset in the
> variable changes - don't forget to run bitbake -c rebuild manually...

Can I get a few comments on [1]? I found there is also a dependency
in libtheora on x11 that doesn't seem necessary. I find this very
useful to avoid making a new recipe. Anyone have ideas to address
Denys' concern about needing to issue 'bitbake -c rebuild'?

[1] http://www.beagleboard.org/gitweb/?p=arago-oe.git;a=commitdiff_plain;h=0b53219005c8daa95bcff40742d7c807bda17eca

For some reason Koen's reply never made it to the oe-dev list... Sorry for
copying it here to continue the discussion.

Koen said:

I'm against adding such 'USE flags' to OE, they basically make QA impossible.
If people want a different mplayer, they are free to make an 'mplayer-nox' or
'mplayer-nosdl' recipe to fill their needs.

But on the other hand it would make overlays, such as Arago, as well as OE
itself, much cleaner and reduce the recipe creep.

As of the rebuild issue when featureset in the variable changes, I was
thinking about storing a hash of variable's value, in addition to the
standard version and revision numbers, should trigger an automatic rebuild.
Similar to bumping up a PR, but without modifying the recipe. Any thoughts?

Is it possible in OE to generate an ipk file name that gives some
indication of the USE flags? Perhaps the right way to do this is with
a common .inc file to avoid maintenance issues.

If it magically mangles package names, what's so different from creating multiple recipes?

regards,

Koen

I think the differences are the names being sensible (based on having
multiple recipes and using a .inc file to avoid maintenance issues)
vs. maintaining fewer recipes. The USE flags also give greater
flexibility at the distribution level, but I've only seen a limited
number of cases for which this is currently required. As long as the
recipes give ?= assignments, "personal" distributions could still be
generated at the local.conf level. The idea to add a hash to trigger
an automatic rebuild if relevant USE flags change still seems quite
useful (and even putting the USE flags into the control file).

That still doesn't the really address QA flaws I pointed out, weakly assigned USE flags should *never* be in OE metadata. If you assing the nosdl flag in the mplayer-nosdl.bb, what's the use of weakly assigning it?

regards,

Koen

Khasim,

below...

All of the DVI-D monitors and PICO that I have tried do not work as well.

With the validation kernel on the wiki, I find that 1280x720M-24@60
works well with my HDTV. The u-boot doesn't provide any splash screen
for me.

Also, note Dirk's comments below.

Gerald

>
> Jason Kridner wrote:
>> Khasim,
>>
>> See below...
>>
>>> Steve K.,
>>>
>>> See below...
>>>
>>>> Based on our meeting this morning, here are the actions I took down
>>>> for
>>>> finalizing our Rev C validation image this week. All validation code
>>>> and
>>>> processes will go on
>>>> Google Code Archive - Long-term storage for Google Code Project Hosting..
>>>>
>>>> Jason:
>>>> * Provide list of commits to pull for u-boot. (This will build the
>>>> recovery
>>>> u-boot that ignores the environment variables on the flash, not just
>>>> the one
>>>> that will go into the flash.)
>>
>> I have applied my patches against the head of your tree on a branch
>> called 'for-khasim':
>>
>> http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/logs/for-khasim
>
> Any plans to fix dss_init() in
>
>
> http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-clone/blobs/for-khasim/board/omap3/beagle/beagle.c
>
> ?
>
> Doing stuff like *((uint *) for register access could be broken? Using
> potentially broken code for validation sounds strange.
>
> Use readx/writex?
>
> Fix hard coded 0x48310034 = 0xfefffedf; stuff?

Dirk,

Can you point to a link/example with the proper format? I assume this
is for the clock init accesses, correct?

Also, I'd really welcome a patch that works on HDTVs and the Pico
projector. The old splash screen worked with the Pico projector and
many HDTVs. The current dss_init() doesn't work with any display that
I have, but it must be working with some DVI-D monitors.

>
>> This is built (and untested) at:
>> http://www.beagleboard.org/~arago/u-boot.bin
>> http://www.beagleboard.org/~arago/u-boot-f.bin
>>
>>>> * Clone Linux kernel w/ OE patches to gitorious in case
>>>> beagleboard.org
>>>> crashes.
>>
>> It will go here when Gitorious I finish uploading it (will apply a
>> validation-20090127 tag):
>> http://gitorious.org/projects/beagleboard-diagnostic-kernel
>>
>>>> * Provide new ramdisk image based on the Arago overlay of Angstrom
>>>> that is
>>>> smaller and will boot faster. (Steve will test.)
>>> Hopefully the mailing list won't find this "down-in-the-guts" work to
>>> be too much noise. I'm hopeful that by being open for the Rev C
>>> release we can generate better support collateral out of the
>>> community.
>>>
>>> I haven't had a chance to test this yet.
>>>
>>> I've generated a new minimal file system build at:
>>>
>>> http://www.beagleboard.org/~arago/arago-deploy/images/beagleboard/arago-base-image-beagleboard.ext2.gz

This seems to have some problems with the inittab. The image on the
Rev C validation wiki page doesn't seem to be compressed, so that may
be some of Gerald's boot performance issues!

>>>
>>> To build this, I used tag "validation-20090127":
>>> http://www.beagleboard.org/gitweb/?p=arago.git
>>>
>>> For mplayer and other utilities, look at:
>>> http://www.beagleboard.org/~arago/arago-deploy/ipk/armv5te/

So far, my attempt to build for armv7a has failed. I'm redoing it
with X-nox.bb files.

Khasim,

below...

> All of the DVI-D monitors and PICO that I have tried do not work as well.

With the validation kernel on the wiki, I find that 1280x720M-24@60
works well with my HDTV. The u-boot doesn't provide any splash screen
for me.

Also, note Dirk's comments below.

> Gerald

>> > Jason Kridner wrote:
>> >> Khasim,

>> >> See below...

>> >>> Steve K.,

>> >>> See below...

>> >>>> Based on our meeting this morning, here are the actions I took down
>> >>>> for
>> >>>> finalizing our Rev C validation image this week. All validation code
>> >>>> and
>> >>>> processes will go on
>> >>>>Google Code Archive - Long-term storage for Google Code Project Hosting..

I've placed several notes on this page regarding issues. Please
provide instructions on exactly what was added to the Arago image.

>> >>>> Jason:
>> >>>> * Provide list of commits to pull for u-boot. (This will build the
>> >>>> recovery
>> >>>> u-boot that ignores the environment variables on the flash, not just
>> >>>> the one
>> >>>> that will go into the flash.)

>> >> I have applied my patches against the head of your tree on a branch
>> >> called 'for-khasim':

>> >>http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-

>> > Any plans to fix dss_init() in

>> >http://gitorious.org/projects/beagleboard-default-u-boot/repos/jason-

>> > ?

>> > Doing stuff like *((uint *) for register access could be broken? Using
>> > potentially broken code for validation sounds strange.

>> > Use readx/writex?

>> > Fix hard coded 0x48310034 = 0xfefffedf; stuff?

>> Dirk,

>> Can you point to a link/example with the proper format? I assume this
>> is for the clock init accesses, correct?

>> Also, I'd really welcome a patch that works on HDTVs and the Pico
>> projector. The old splash screen worked with the Pico projector and
>> many HDTVs. The current dss_init() doesn't work with any display that
>> I have, but it must be working with some DVI-D monitors.

>> >> This is built (and untested) at:
>> >>http://www.beagleboard.org/~arago/u-boot.bin
>> >>http://www.beagleboard.org/~arago/u-boot-f.bin

>> >>>> * Clone Linux kernel w/ OE patches to gitorious in case
>> >>>> beagleboard.org
>> >>>> crashes.

>> >> It will go here when Gitorious I finish uploading it (will apply a
>> >> validation-20090127 tag):
>> >>http://gitorious.org/projects/beagleboard-diagnostic-kernel

>> >>>> * Provide new ramdisk image based on the Arago overlay of Angstrom
>> >>>> that is
>> >>>> smaller and will boot faster. (Steve will test.)
>> >>> Hopefully the mailing list won't find this "down-in-the-guts" work to
>> >>> be too much noise. I'm hopeful that by being open for the Rev C
>> >>> release we can generate better support collateral out of the
>> >>> community.

>> >>> I haven't had a chance to test this yet.

>> >>> I've generated a new minimal file system build at:

>> >>>http://www.beagleboard.org/~arago/arago-deploy/images/beagleboard/ara

This seems to have some problems with the inittab. The image on the
Rev C validation wiki page doesn't seem to be compressed, so that may
be some of Gerald's boot performance issues!

The inittab issue was actually due to a typo in my bootargs. I've
placed bootargs that work with my HDTV in the wiki comments.