We are planning to have the BeagleBoard-xM boot up to hd720 by
default, but were considering using 640x480 when booting the
validation ramdisk image. Gerald, however, has a monitor on his desk
that doesn't like the 640x480 mode. I was thinking it would be the
most compatible, even working with things like the pico projector, but
the point that HDTVs are probably the most likely thing to connect up
to your BeagleBoard sounds like a reasonable argument.
What mode should we use when running the validation environment? Are
we all happy with hd720 (720p60)?
We are planning to have the BeagleBoard-xM boot up to hd720 by
default, but were considering using 640x480 when booting the
validation ramdisk image. Gerald, however, has a monitor on his desk
that doesn't like the 640x480 mode. I was thinking it would be the
most compatible, even working with things like the pico projector, but
the point that HDTVs are probably the most likely thing to connect up
to your BeagleBoard sounds like a reasonable argument.
Would it be worth it to try and ping/detect the Pico on the i2c bus?
While speaking about I2C - Why not read EDID from the monitor and set
resolution accordingly?
I know it's a little bit of a bigger task, so meanwhile I will recommend
setting the resolution to either 1024x768 or hd720...
Søren
We are planning to have the BeagleBoard-xM boot up to hd720 by
default, but were considering using 640x480 when booting the
validation ramdisk image. Gerald, however, has a monitor on his desk
that doesn't like the 640x480 mode. I was thinking it would be the
most compatible, even working with things like the pico projector, but
the point that HDTVs are probably the most likely thing to connect up
to your BeagleBoard sounds like a reasonable argument.
Would it be worth it to try and ping/detect the Pico on the i2c bus?
We are planning to have the BeagleBoard-xM boot up to hd720 by
default, but were considering using 640x480 when booting the
validation ramdisk image. Gerald, however, has a monitor on his desk
that doesn't like the 640x480 mode. I was thinking it would be the
most compatible, even working with things like the pico projector, but
the point that HDTVs are probably the most likely thing to connect up
to your BeagleBoard sounds like a reasonable argument.
Would it be worth it to try and ping/detect the Pico on the i2c bus?
While speaking about I2C - Why not read EDID from the monitor and set
resolution accordingly?
Do you have any EDID parsing code that can go into either u-boot or the kernel?
We are planning to have the BeagleBoard-xM boot up to hd720 by
default, but were considering using 640x480 when booting the
validation ramdisk image. Gerald, however, has a monitor on his desk
that doesn't like the 640x480 mode. I was thinking it would be the
most compatible, even working with things like the pico projector, but
the point that HDTVs are probably the most likely thing to connect up
to your BeagleBoard sounds like a reasonable argument.
Would it be worth it to try and ping/detect the Pico on the i2c bus?
Any way to do that in u-boot?
My first thought was to expand the stuff koen did for detecting the
expansion boards in u-boot..
That patch just reads the EDID, it doesn't parse it. There are open
source utilities that parse it, but I don't have the time to create a
u-boot patch in the next 24 hours.
I think a lower resolution is better.
Most of my computer monitors do not currently support hd720
I think they all support 800x600
Would you agree with others suggesting 1024x768?
My experience is that HDTVs don't like monitor resolutions like that,
but I think having the main image go 720p and having the ramdisk image
go 1024x768 should be reasonable--with only things like the pico
projector (640x480) being left out.
Do you have any EDID parsing code that can go into either u-boot or the
kernel?
I do (unfortunately) not have any EDID code on stock, which was why I
suggested that we should start with a fixed resolution, but try to make a
move to reading and using EDID in the future, since I think we have been
discussing selecting the best possible video resolution several times in the
past as well.
Do you think everybody has hd720 monitors? Anyway my FullHD display handles well 1024x768 resolution. Things just look a little bit wider than they should be
What did you end up with please? I think it was 640x480 but at what
frame rate? On my XM it
produces a frame rate of 14Hz after 'u-boot.bin' which cannot suit
anybody! OK it's fine
after Angstom loads (about 4 times faster).
What did you end up with please? I think it was 640x480 but at what
frame rate? On my XM it
produces a frame rate of 14Hz after 'u-boot.bin' which cannot suit
anybody! OK it's fine
after Angstom loads (about 4 times faster).
Once the Linux kernel loads, it is 1024x768@60fps. There is a bug in
the clocks of u-boot that we didn't bother to fix because we are
booting up in to Linux by default with what ships with the boards now.
*****CARE REQUIRED HERE******
You can invoke 'edituserscr' to alter the settings. I recommend doing:
The default 'nano' editor doesn't work well over HyperTerminal, but
I'd recommend not using 'export EDITOR=vi' if you are using the
BeagleBoard console directly or are not familiar with 'vi'. If you
aren't familiar with 'vi' and are using the serial port, I recommend
not using HyperTerminal or debugging that configuration.
Change settings to what you'd like by editing the 'setenv dvimode
1024x768MR-16@60' line to your desired mode. 'setenv dvimode hd720'
is valid.
What did you end up with please? I think it was 640x480 but at what
frame rate? On my XM it
produces a frame rate of 14Hz after 'u-boot.bin' which cannot suit
anybody! OK it's fine
after Angstom loads (about 4 times faster).
Once the Linux kernel loads, it is 1024x768@60fps. There is a bug in
the clocks of u-boot that we didn't bother to fix because we are
booting up in to Linux by default with what ships with the boards now.
*****CARE REQUIRED HERE******
You can invoke 'edituserscr' to alter the settings. I recommend doing:
I forgot to say that the reason to do this is so that you can still
use the USER button at boot to go back to a known good boot script.
'boot.scr' will be ignored if the USER button is held down at boot,
but be sure to press the USER button down *AFTER* you have applied
power because the BOOT_SEL pins would otherwise be pulled to an
invalid boot mode for trying to boot off of the SD card.
