You can connect SDA (pin 22 on the BCM20732S module) to GND only during boot and then disconnect pin 22 from GND when ready to download new application to the EEPROM.
The TAG board used the 20732 SOC: http://community.broadcom.com/docs/DOC-1404
The clock pin (SCL) and data pin (SDA) are both open-drain I/O pins. Pull-up resistors external to the
BCM20732 are required on both the SCL and SDA pins for proper operation.
This post describes the function of the BOOT_ROM switch during reset, which is used to put the board into a known state for recovery: http://community.broadcom.com/message/3772#3772
The answer to your question must lie in the means by which the pin is sampled in firmware during the boot process. I believe this to be the case because the I2C spec requires a pull up on SCL and SDA. In addition, I am told that the internal pull up is not sufficient because it will not be "configured" until an I2C slave is detected.
If VDDIO is present on SDA, then the part bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode. However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior.
I will ask someone from the Apps team to add some clarity to this behavior.
I assure you that the schematic is not wrong.
I Looked into this and as it turns out, connecting SDA to Vdd/Vio to recover is not optimal.
SCL and SDA are both open-drains and the internal pull-ups are actually pulling the signal high while the hardware drives it low (i.e. hardware never drives the pin high, but it floats the output pad leaving the pull-up to pull the line high). If you were to put a scope to either of these signals during firmware access, you will see high to low transitions that are very sharp while the low to high transitions will be fairly slow due to the intrinsic RC.
If you connect SCL/SDA to Vdd, when the hardware block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot process because the ROM always uses 0xA0 as the slave address of the EEPROM and you will be able to see that there are repeated 0s in this sequence (and the shorts) which may cause issues with the supply or the chip itself.
Shorting to GND on the other hand is safer because that's precisely what happens when there is a 0 bit on the bus and there is a 10K pull-up, which will limit the current to something within the max ratings of all components on this line.
The reason recovery works under this scenarion is because the data on the i2C bus is invalid when its shorted to GND. When the ROM tries to read from slave 0xA0, the actual data bytes on the bus are overridden to 0x00, which is not a valid slave. Once this occurs, the ROM immediately gives up on the EEPROM and goes into download mode if uart is also connected.