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
