Echo's Testpad Details and a cautionary tale

[gssincla]

Back in February opiette posted some details about the testpads at the bottom of the Echo (see this post http://www.piettes.com/echo/viewtopic.php?f=6&t=20&sid=6aef15a0b7707bad128f496a7d0bea86) I decided to try to expand this knowledge base today with some interesting ... and some annoying... results. First, the good information:

Looking at the bottom of the Echo you can find a set of testpads in a 4 x 5 grid configuration. See the iFixIt.com's picture of the board here:

Those testpads in the larger B and C boxes contain a wealth of hardware hacking goodies! These are the pads, for instance, that give us console access during boot up (see my previous post about the u-boot startup sequence to get an example of the output). I soldered leads to each of the pads (with 5 exceptions that i'll mention shortly) so I could start figuring out what is what. This is what I found (or confirmed, in some cases, from opiette's post):

B Block:

• TP88 - GND
• TP69 - goes to J21, pin 10
• TP67 - goes to J21, pin 16
• TP98 - +15v
• TP4 - +15v
• TP1 - GND
• TP101 - Blue LED on lower board, goes to J21, pin 9
• TP96 - GND
• TP65 - Serial RX line (goes to J21, pin 10)

C Block:

• TP68 - goes to J21, pin 17
• TP100 - Orange LED on lower board, goes to J21, pin 12
• TP99 - GND
• TP2 - FACTORY RESET (this will factory reset your Echo after the kernel boots) Goes to J21, pin 14
• TP73 - goes to J21, pin 19
• TP71 - goes to J21, pin 18
• TP70 - goes to J21, pin 15
• TP72 - goes to J21, pin 13
• TP64 - Serial TX line (goes to J21, pin 11)

I did not wire up the +15v lines and 3 of the 4 GND wires because I don't need them since they are supply lines, not logic lines. The GND line, by the way, goes to J21, pin 8.

The serial line is 115200 8N1 but not 5v, lower. 3.3v seems to be ok. opiette said he tested it at 1.8v, but I just hooked up my board and didn't bother to look at the voltages. I probably should at some point.

For those interested, here is a sample of the timing of LED signals during the boot-up:


Now for the part of the story that is the cautionary tale....

With the testpads all decked out in test leads I hooked up the BitScope in logical analyzer mode to see what was happening on these lines. I started simple by looking at TP70 and TP72. I booted up my Echo and things started going bad... fast!  The boot log showed the Echo reboot rapidly. So I quickly pulled the power and looked at the log. Seems the Echo is now trying to boot from "main-B" instead of "main-A". If you are thinking to yourself "self, this seems bad" You are right. This is bad. Immediately following this new boot device declaration I see it saying

*
Booting from mmc...
** File not found /boot/uImage **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
resetting...

and then it resets. over. and over. and over again. I'm not exactly sure what has happened here. Digging through the source code I found this in uboot\board\ti\lab126\partition.c:

/** Main-A Partition UUID - 7c688c84-b864-44ea-910a-d97922ddd5e0*/
static const u8 main_A_uuid[UUID_SIZE] = { 0x84, 0x8c, 0x68, 0x7c, 0x64, 0xb8,
      0xea, 0x44, 0x91, 0x0a, 0xd9, 0x79, 0x22, 0xdd, 0xd5, 0xe0, };

/** Main-B Partition UUID - 7733bee4-42fd-45dd-a77d-e99b9458e5cf*/
static const u8 main_B_uuid[UUID_SIZE] = { 0xe4, 0xbe, 0x33, 0x77, 0xfd, 0x42,
      0xdd, 0x45, 0xa7, 0x7d, 0xe9, 0x9b, 0x94, 0x58, 0xe5, 0xcf, };

----- many lines below this -------

// TODO: Read the partition table from mmc-1
static struct fbt_partition fbt_partitions[] = {
      { "-", 128, NULL, NULL },
      { "xloader", 896, "raw", xloader_uuid },
      { "recovery", MB * 16, "fat", recovery_uuid },
      { "boot", MB * 16, "fat", boot_uuid },
      { "idme", MB * 16, "ext3", misc_uuid },
      { "diags", MB * 128, "ext3", mfg_uuid },
      { "main-A", MB * 512, "ext3", main_A_uuid },
      { "main-B", MB * 512, "ext3", main_B_uuid },
      { "data", 0, "ext3", data_uuid },
      { 0, 0, NULL, NULL },
};

and in uboot\common\cmd_idme_emmc.c, there is this bit of information:

#define IDME_BOOT_BACKUP_DATA \
      "bootmode=main-A\nknowngood=main-B\notaretrycount=2\npostmode=idmerecovered\n"

I guess I don't have a "known good" partition? Digging a bit more, the selection of main-B happens in prepare_eMMC_boot within the uboot\board\ti\lab126\evm.c when it calls

   if (idme_get_var("bootmode", boot_mode, sizeof(boot_mode)))
   {
      printf("failed to get bootmode var - default to main-A\n");
      // TODO: Handle corruption...this should always succeed !
      memcpy(boot_mode, main_a_label, sizeof(main_a_label));
   }

this means, if I'm reading this correctly, that somehow my nvram got flipped. I obviously haven't completely bricked this device since I can still get X-loader and u-boot to operate, but something has definitely gone bad just from those two lines. I'm hoping I can either figure out how to do a VERY hard reset to get it back in line or how to attach a SD card to it so I can get at the nvram to repair it. If anyone has any experience here with this type of error, I'd love an assist 

[gssincla]

I don't have definitive proof yet, but it looks like TP67 is the line being referred to when u-boot displays the line

Card did not respond to voltage select!

TP69, TP70, TP71, TP72 and TP73 seem to exhibit the same behavior and timing, but TP67 seems to have a unique behavior that when overlayed against the others would indicate it is being actively triggered. Take a look at the scope output below:


The green line is TP67 and the yellow line is TP71.

TP68 seems to be grounded in some way. It exhibits only low voltage noise.