Re: [Gumstix-users] Modifying omap3_overo.h does not modify output of overo#printenv - why?

[Robert C. <rc...@ae...>]

I've had to modify some kernel reboot parameters before.  The .h file
you're referencing is changed by a patch file, so changing it won't
probably work.

I suggest taking a look at one of my postings about modifying the kernel
command line.

You might see something that'll help

http://old.nabble.com/FYI---steps-to-modify-kernel-boot-command-line-to32625614.html#a32625614

-cy

On Wed, Nov 9, 2011 at 8:16 PM, chr...@gm...
<chr...@gm...>wrote:

>
> A bit of followup:
>
> 1) I've tried looking at the u-boot.bin generated in the u-boot tmp
> directory; it does not contain the string "defaultdisplay=lcd43". It does,
> however, have long strings of nandarguments and mmcarguments referring to
> ${defaultdisplay}, which is earlier declared to be equal to "dvi".
> Therefore
> the problem is in compilation somewhere.
>
> 2) Modifying the u-boot/tmp directory's copy of u-boot.bin to have the
> desired string value of "defaultdisplay=lcd43" makes a boot with that
> u-boot.bin binary fail, as might be reasonably expected. Whups.
> 2b) However, copying that binary onto my uSD card and then checking for
> presence of string "defaultdisplay=lc343" in the uSD card's copy of
> u-boot.bin confirms that at least the file copying operation is working as
> expected.
>
> My current source of mystification, then, is why
> $bitbake -c clean u-boot
> $bitbake -c clean virtual/bootloader
> $bitbake virtual/bootloader
>
> does not create a binary image with the string as defined by omap3_overo.h
> .
> My best speculation on a cause for this is that an intermediate product of
> the compilation process is not getting removed by the -c clean directive
> and
> is acting as a cache for the string's old value. My next question, then -
> if
> -c clean isn't sufficient to rebuild u-boot and all its dependencies from
> scratch, what is? My not-best speculation on the cause is that other
> options
> set in omap3_overo.h, like dvimode, are getting caught by a preprocessing
> script which then undoes the change I made to defaultdisplay to preserve
> sanity.
>
> Can anyone provide any feedback for these theories, or a fix for the issue
> I'm seeing?
> thanks in advance,
> Chris
>
>
> chr...@gm... wrote:
> >
> > Hi, all.
> >
> > Having confirmed that my build environment appears to be operating
> > correctly, I would now like to configure my Tide+Chestnut43 to boot using
> > the touchscreen without my having to intervene each time during the boot
> > process. http://www.gumstix.org/getting-started.html tells me to modify
> > omap3_overo.h to do so, but does not provide specifics; I assumed that
> > changing 'defaultdisplay=dvi' to 'defaultdisplay=lcd43' would be
> > sufficient, but when I check the output of printenv after building with
> > the modified header, defaultdisplay is still 'dvi'. The system uses the
> > display happily when I manually set the variable via u-boot, so I've got
> > the right system image... but why are my changes not being reflected in
> > system behavior? Where are they being overridden?
> >
> > Thanks in advance,
> > Chris
> >
>
> --
> View this message in context:
> http://old.nabble.com/Modifying-omap3_overo.h-does-not-modify-output-of-overo-printenv---why--tp32788700p32815682.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> gumstix-users mailing list
> gum...@li...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>



-- 
Robert Corley