On Sun, Sep 27, 2009 at 7:21 AM, Tom <tom....@windriver.com> wrote: > Steve Sakoman wrote: >> >> On Sun, Sep 27, 2009 at 4:52 AM, Tom <tom....@windriver.com> wrote: >>> >>> Steve Sakoman wrote: >>>> >>>> On Fri, Sep 25, 2009 at 1:47 PM, Tom <tom....@windriver.com> wrote: >>>>> >>>>> Dirk Behme wrote: >>>>>> >>>>>> From: Steve Sakoman <sako...@gmail.com> >>>>>> >>>>>> Update default environment to support new kernel DSS2 subsystem and >>>>>> simplify rootfs type and location changes. >>>>>> >>>>>> Signed-off-by: Steve Sakoman <sako...@gmail.com> >>>>>> Signed-off-by: Dirk Behme <dirk.be...@googlemail.com> >>>>>> >>>>>> --- >>>>>> include/configs/omap3_beagle.h | 27 +++++++++++++++++++-------- >>>>>> include/configs/omap3_overo.h | 27 +++++++++++++++++++-------- >>>>>> 2 files changed, 38 insertions(+), 16 deletions(-) >>>>>> >>>>>> Index: u-boot-ti/include/configs/omap3_overo.h >>>>>> =================================================================== >>>>>> --- u-boot-ti.orig/include/configs/omap3_overo.h >>>>>> +++ u-boot-ti/include/configs/omap3_overo.h >>>>>> @@ -155,16 +155,27 @@ >>>>>> #define CONFIG_EXTRA_ENV_SETTINGS \ >>>>>> "loadaddr=0x82000000\0" \ >>>>>> "console=ttyS2,115200n8\0" \ >>>>>> - "videomode=1024x...@60,vxres=1024,vyres=768\0" \ >>>>>> - "videospec=omapfb:vram:2M,vram:4M\0" \ >>>>>> + "vram=12M\0" \ >>>>>> + "dvimode=1024x768mr...@60\0" \ >>>>>> + "defaultdisplay=dvi\0" \ >>>>>> + "mmcroot=/dev/mmcblk0p2 rw\0" \ >>>>>> + "mmcrootfstype=ext3 rootwait\0" \ >>>>>> + "nandroot=/dev/mtdblock4 rw\0" \ >>>>>> + "nandrootfstype=jffs2\0" \ >>>>>> "mmcargs=setenv bootargs console=${console} " \ >>>>>> - "video=${videospec},mode:${videomode} " \ >>>>>> - "root=/dev/mmcblk0p2 rw " \ >>>>>> - "rootfstype=ext3 rootwait\0" \ >>>>>> + "vram=${vram} " \ >>>>>> + "omapfb.mode=dvi:${dvimode} " \ >>>>>> + "omapfb.debug=y " \ >>>>> >>>>> Is setting the debug option needed ? >>>>> This would seem useful (from the name) only to developers >>>> >>>> DSS2 is still under active development. This setting makes user >>>> support easier since boot logs contain needed debug info. >>>> >>> Or it turns them all into beta-testers. >>> It is a toss up if this is a good thing >>> I will go with it. >>> OK. >> >> Heh, like it or not we are all beta testing DSS2! It is so much >> better than the old DSS code that I want to do everything possible to >> help Tomi get it accepted upstream as quickly as possible :-) >> >>>>>> + "omapdss.def_disp=${defaultdisplay} " \ >>>>>> + "root=${mmcroot} " \ >>>>>> + "rootfstype=${mmcrootfstype}\0" \ >>>>>> "nandargs=setenv bootargs console=${console} " \ >>>>>> - "video=${videospec},mode:${videomode} " \ >>>>>> - "root=/dev/mtdblock4 rw " \ >>>>>> - "rootfstype=jffs2\0" \ >>>>>> + "vram=${vram} " \ >>>>>> + "omapfb.mode=dvi:${dvimode} " \ >>>>>> + "omapfb.debug=y " \ >>>>>> + "omapdss.def_disp=${defaultdisplay} " \ >>>>> >>>>> From vram to omapdss.def_disp are common for nand and mmc. >>>>> These should be changed to something like >>>>> >>>>> "videoargs= .... " >>>>> >>>>> Similar for beagle. >>>> >>>> I'm not sure exactly what you are suggesting. The current setup is >>>> tailored to make user support easier. >>>> >>>> If someone wants to use the 4.3" LCD display option, you tell them to >>>> simply type: >>>> >>>> setenv defaultdisplay=lcd43 >>>> saveenv >>>> >>> Yes I see how just a single video_args= would not give you this >>> flexiblity. >>> A lesser way to do this would be to that you may want to do is >>> video_args="${defaultdisplay} ${dvimode} .. " >> >> I agree that would be nice, and in fact that is the way I did it >> initially. But for some reason it didn't work. I didn't spend a lot >> of time investigating, but it seemed that there was a limit to how >> many "layers" of variable definitions you could have. I won't rule >> out operator error though! >> >> Steve >> > > Sounds like you have thought this stuff through. > The video_args is just a nice-to-have. > > Ack
I'm a bit confused! This patch made it into the u-boot-ti tree and then disappeared during one of the rebasings. Does this mean it is rejected, or perhaps just lost in the shuffle? Steve _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot