From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Date: Sun, 27 Sep 2009 09:21:43 -0500 Subject: [U-Boot] [PATCH] OMAP3: Update Overo and Beagle environment In-Reply-To: <5e088bd90909270702i7271ea0doe8359a915c9f8229@mail.gmail.com> References: <1253904594-30105-1-git-send-email-dirk.behme@googlemail.com> <4ABD2C5F.30102@windriver.com> <5e088bd90909260641q6b5a3b03j9492c0c0f7f73c1b@mail.gmail.com> <4ABF51F8.9040009@windriver.com> <5e088bd90909270702i7271ea0doe8359a915c9f8229@mail.gmail.com> Message-ID: <4ABF74F7.50700@windriver.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Steve Sakoman wrote: > On Sun, Sep 27, 2009 at 4:52 AM, Tom wrote: >> Steve Sakoman wrote: >>> On Fri, Sep 25, 2009 at 1:47 PM, Tom wrote: >>>> Dirk Behme wrote: >>>>> From: Steve Sakoman >>>>> >>>>> Update default environment to support new kernel DSS2 subsystem and >>>>> simplify rootfs type and location changes. >>>>> >>>>> Signed-off-by: Steve Sakoman >>>>> Signed-off-by: Dirk Behme >>>>> >>>>> --- >>>>> 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=1024x768 at 60,vxres=1024,vyres=768\0" \ >>>>> - "videospec=omapfb:vram:2M,vram:4M\0" \ >>>>> + "vram=12M\0" \ >>>>> + "dvimode=1024x768MR-16 at 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 Tom