Gerald, I understand that the HDMI chip is all inputs and would not contend for that signal. I was asking about possible contentions between the processor driving a pin and a cape driving the pin to a different state. I had heard that the AM335x have somewhat fragile pins and did not want to stress that by driving a low onto a high level AM335x output pin, for example. I don’t know enough about the kernel to know how to read its code, but Jason seems to be saying that the BBB will do the right thing as long as the cape’s EEPROM is correct.
Oh. My suggestion is don’t do it. In some cases it may not be an issue, but in the general terms under which you ave provided, I would not do it. In the datasheet is the default values of all pins at power up. Some are high and some low. In a lot of cases this is done via a weak pull up or pulldown. In those cases, you may be OK, BUT you need to know EXACTLY what the initialization code does on boot up. The setting of these pins for use on a cape take place AFTER power up, so it may be that these pins are predisposed to be something that could cause you issue. You just need to know the default function of the pins via SW and determine what you may need to do to prevent issues. What Jason is saying is that it will do the right thing AFTER it is all powered up. If things are done incorrectly this will not prevent a scenario that can cause damage It will insure that it functions, as long as something is not damaged. again, look closely at the default on power up of all pins and the default mode that Uboot and the initialization sets each pin to. I have those listed in the SRM and have asked that the SW set everything in those modes, but I don’t know that i has been done in all cases.
More importantly, no pins should be driven until AFTER the 3.3V rail on the expansion headers is powered completely up. Otherwise you run a risk of damaging the pin by violating the power up sequence.
Simplest way to be safe is that you don’t drive any outputs until after initialized, maybe use a pin to turn things on. But if the SW sets things up as defined in the SRM, and you use those pins for that function, then you should have no issues. It is just when you want to use those pins for something other than the way the SW sets them up initially that there could be issues.
Gerald
Oh. My suggestion is don’t do it. In some cases it may not be an issue, but in the general terms under which you ave provided, I would not do it. In the datasheet is the default values of all pins at power up. Some are high and some low. In a lot of cases this is done via a weak pull up or pulldown. In those cases, you may be OK, BUT you need to know EXACTLY what the initialization code does on boot up. The setting of these pins for use on a cape take place AFTER power up, so it may be that these pins are predisposed to be something that could cause you issue. You just need to know the default function of the pins via SW and determine what you may need to do to prevent issues. What Jason is saying is that it will do the right thing AFTER it is all powered up. If things are done incorrectly this will not prevent a scenario that can cause damage It will insure that it functions, as long as something is not damaged. again, look closely at the default on power up of all pins and the default mode that Uboot and the initialization sets each pin to. I have those listed in the SRM and have asked that the SW set everything in those modes, but I don’t know that i has been done in all cases.
Correct. I am saying you can use the pins given configuration from CapeMgr and the drivers, but all shared pins need to be negotiated prior to being driven!