I fiddled with the u-boot env variables tonight to try and resolve the s-video problem.  One trick from the beagleboard mailing list said to set omapfb.mode=tv:ntsc and omapdss.def_disp=tv.  I tried this but found that if I tried to run the boot manually  to pick up these changes to the bootargs the boot failed for various reasons related to how the rest of the environment is set up.  The only boot that works (albeit without S-video support properly configured) is the default boot.  This boot reads the boot.scr file from the sd card, which is a text file from the angstrom distro that has been run through with the mkimage tool from u-boot.  Browsing recipes/angstrom/angstrom-uboot-scripts I find a couple of possible scripts that may be the one being used for boot.scr.  I'll either have to decipher the angstrom build process for BeagleBoard or just ask on the mailing list for which one is the one used to create the validation images for the C4 boards.

This idea of setting up u-boot via files on the SD card is interesting.  I can see why they'd want to do it – it's easier to reconfigure u-boot by updating a file on the SD card than trying to rebuild u-boot and/or flashing a ROM.  What I don't think I like (at least not yet, I may change my mind) is how this differs from the way u-boot is used in general.  Maybe this has always been done and I've just never seen it.  But its another step in my build process that I'll need to add if I want to keep using the current x-loader on the C4 board I have.

Of course, if I change the boot loader (u-boot) on the SD card to something other than what the BeagleBoard validation images use it's questionable if the use of the boot scripts will still work.  I'm not sure if the x-loader is loading u-boot from the SD card initially and *that* is the one that calls the boot.scr or if there is a u-boot in the ROM that loads first and *that* is the one whose env vars I've been mucking with.

I think I need to ask the list for help on this.  If anyone reads this and has the answer, please post a comment.  Thanks!

update: 2010-10-20

D'oh!  Stupidity is setting in.  It's obvious there are two u-boots.  The first one provided me the command line interface.  I know this because I actually loaded the second one from the SD card!

• mmc init
  
• fatload mmc ${loadaddr} uImage.bin

The first command initialized access to the SD card.  The second read the u-boot image from the card into an address.  When I booted I ran what was at that address.  Thus: 2 u-boots.

So my changes to the env vars within the first u-boot obviously never got picked up by the second one.  And the second one gets its environment settings from the *.scr scripts.  So the only way to really change the environment is to create these scripts in text files and then turn them into image files with u-boot's mkimage.  Well, that's not completely true but it is true if I want to continue using the x-loader/u-boot already stored in ROM on the board.  And I still need to make sure that my u-boot on the SD card is configured properly to pick up the boot scripts.  I need to make sure it is.

It's amazing what a bad-night's sleep can expose.

Update: 2010-10-21

And so it seems a night's missed sleep doesn't always help.  According to JKridner on the BeagleBoard latest news feeds (thanks to him for offering some insight on this):

This post is wrong , but highly appreciated to explain what a user's experience might be. uImage.bin is the linux kernel, not u-boot. I'm not sure what the two u-boots could be, but if you have a C4, there could be one in the flash as well as one on the SD card.

And so it is.  Yet again – D'OH!  Yes, I knew that uImage was the kernel.  But I am, at far too frequent times these days, too stupid to pay attention to even what I'm writing, much less doing.  Note that it's easy to verify if u-boot is in nand:  don't use an SD card and see if you can interrupt the boot.  The x-loader may offer a command line but something tells me it doesn't (need to verify that).  Also, use an SD card but leave off the u-boot images (the one titled u-boot.bin and the one titled u-boot-f.bin).  I need to identify which u-boot is reading the scripts.  That way I can decide if I need one on the SD card or not.  Automatic updates to u-boot on NAND might require it, but the question is “is the u-boot on SD required?”  I'll be in better shape when I can answer that question.

In any case, I've been formulating my ideas on how I want it to work for BeagleBox.  Assuming only one u-boot is running (be it from flash or SD card), I want to use it to read the scripts to handle my configuration.  I can automate their generation as part of the build process for BeagleBox.  But I better get a tighter grasp on exactly how this is all working if I expect to make this thing work correctly.  Accidentally on purpose doesn't count.  I'm still trying to figure out what the MLO image is for – I'd found it once before so hopefully it's in my blog somewhere.

Finally, I guess I'm going to have to give more attention to working on this than an hour before The Daily Show each night.  Especially when I'm going to have to start back into working on the update to my last gimp book.  I NEED TO FOCUS!!!!