OK, so let's try to take this problem apart a bit further...
I am out of the office today, and don't have access to my board for experimenting.
In this one I see what may be the root cause of your problem. To confirm this, I'd like you to repeat a couple steps here:
Use imx_usb to load the known correct u-boot like you did yesterday.
Either interrupt the 1 second delay, or wait for u-boot to fail finding the kernel and, either way, enter the following command at the prompt:
In u-boot try the command 'sf probe' and it should discover the NOR FLASH device.
If it fails to do so, then you need to contact the board manufacturer for support, not Freescale.
That problem is on the Boundary Devices board, so you will have to contact them for support on that problem.
I am attaching a whitepaper I wrote for my client to update the NOR FLASH. I did not use the upgradeu script, and I think it was because of the fact it didn't work right - which is your problem. So if you think that your u-boot is not properly stored in NOR FLASH then try what I outlined in the attached document.
Looking at YOUR environment, it wanted to run the 6q_upgrade script - mine wanted to run 6x_upgrade. That is why I renamed the script in the steps I outlined yesterday.
It looks like the u-boot environment is also in NOR FLASH, and here is, I think, possibly the root cause of your problem:
It looks like the sf probe function failed, meaning you might have a defective FOR FLASH part.
How it got defective doesn't matter to you just now, but look in my attached white paper.
As for why all this is 'necessary' and a couple other things you asked/mentioned:
I am just sharing my thinking on what to do next, hoping you might get inspired...
--------------- SabreLite's boot switches
Let me try to answer about the switches and why these steps are 'necessary' for your case:
Here is an almost completely useless excerpt from the unbricking instructions website. What I don't see on my board is any notation indicating their use, per the website:
00 – Fuses
01 – USB
10 – Internal
So, I'll take 00 to be both switches toward the CPU, but then which is 01 and which is 10?
When in the position YOU describe, I got the board trying to boot to a USB device. so I presume that is '01'
When in the position I describe, I got the Freescale Blank ARIK device on my PC USB bus, so I presume that is '10'
Ahh well, it looks like you MAY have gotten u-boot loaded and running, but not saved...
Now, so let's take that victory and move on with the experiment I described above.
I apologize for not capturing the console log for my boot update, it seemed to have worked and I moved on...
My bad there.
But I started this post off with what I think may be the problem you are having...
So, if that was NOT the problem, I'll see if I can come up with some next steps.
--------------- Hide the u-boot
Boundary Devices has made this what I would consider unnecessarily complex...
They put u-boot and its environment into a serial NOR FLASH device on an SPI port.
They also require your use of a boot script in the 'boot partition' of the 'boot' device. That way u-boot and its environment don't need to know so much about the target system - in their minds, anyway.
So your 'boot' device only has its own partition table, the kernel and device trees, and the root filesystem.
- That is the new-traditional arrangement, anyway...
So, you need to be able to update NOR FLASH to get a compatible u-boot loaded. When you do this, it may break the system for the media you originally got.
My attached paper, or the unbricking instructions, can be used to get you back to the older u-boot, if you really want to do so. You should be able to get older u-boot builds from Boundary Devices for their boards.
To figure out what they are doing, read and analyse the 'helper' scripts they provide like upgradeu and bootcmd. This is a complex process, and 'they' really have tried to make it as 'simpler' as they can.
--------------- partitioning in the 'boot' device
Long Long ago, in Linux land, about 2 years for us in the real world, they did not use the device tree for embedded linux systems. They put u-boot, environment, and kernel into unpartitioned space and the root filesystem into a data partition, and it was good -- for then... but too many people wanted to make their own boards, so it got bad...
But someone invented the 'device tree' to 'simplify' the board support process, and Linux saw that it was even better, and so they changed everything - because they can do that... So, now, we traditinoally have u-boot in the unpartitioned space, and then a small FAT32 partition with the kernel and a variety of device tree blobs, and maybe a script or two, and then a Linux partition with the root filesystem for Linux.
If you want to know more, google for information on the migration to the device tree and the Linus Torvalds rant on how too many people are designing boards and it's just getting too complex to manage everything... It's really kind of funny since he is complaining about the comparative success of his own ideas...
Eventually - perhaps sooner than you like - you will probably need to learn about it.