From mboxrd@z Thu Jan 1 00:00:00 1970 From: Can Aydin Date: Mon, 03 May 2010 12:38:19 +1000 Subject: [U-Boot] Toggling pins using the BDI3000 In-Reply-To: <4C070C16.5000001@denx.de> References: <4BB238E9.7060609@denx.de> <20100330203400.8EBE5E73028@gemini.denx.de> <4BB2785B.50003@gmail.com> <4C070C16.5000001@denx.de> Message-ID: <4BDE371B.6050001@locatacorp.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi All, I'm not sure if this is the place to ask this, please redirect if it isn't. I'm looking into using a BDI3000 with a P2020RDB evaluation kit we've already purchased from Denx, but there is some confusion over how the board hardware handles the power on boot configuration signals to the processor. The addenda to the P2020RDB manuals provided by Freescale seem to indicate that certain boot functions that are supposed to be configurable using dipswitches on the board do not work as they should, notably certain clock speeds and the SPI and eSDHC boot configurations, which are the two options I am keen to exercise before moving on to prototyping. Is a BDI3000, (using bdiGDB?), able to override the signals on these pins using JTAG functionality? Essentially, what I would like is some way of finding out if the P2020 is obtaining the correct PLL ratio and boot ROM location from the signals, and more importantly, override any erroneus signals that the hardware on the platform (P2020RDB and later, the prototype) might be providing (or failing to provide) it. (without using an oscilloscope and a soldering iron that is). Regards, Can Aydin -- *Can Aydin* Software Engineer Locata Corporation can.aydin at locatacorp.com Locata Corporation Pty Ltd Level 1, 111 Canberra Ave Griffith ACT 2603 Australia Phone +612 6126 5734 Fax +612 6126 5704