[U-Boot-Users] Can a BDI2K be used with a bare/erased 834x based system?
We're getting our custom HW in about a month and my HW designer came across something in the PowerQUICC Design Checklist that we hadn't considered. (BTW, our board is based around the MPC8347.) The following is a direct quote from the Checklist:
"There may be issues with you usa a JTAG-based in-circuit emulator to boot the PowerQUICC Pro II device as reset configuration words are sourced from an unprogrammed Flash device on the local bus. There is no valid RCW already present in Flash memory when the PowerQUICC II Pro device performs the \PORESET sequence. The CPU core is disabled and the in-circuit emulator cannot take conrtol of the CPU."
It never occured to me that this may be an issue as this is the first processor I've brought up that didn't get it's reset state from processor pins. I had planned on using the BDI2K to do the flash programming on our prototypes, but if I can't get the BDI2K to take control of the the processor I can't do the programming. Not a big deal, we have alternatives that we've thought of, but I'm curious about the "RCW" line in the configuration file. The BDI2K manual states the following for the RCW:
"When this line is present, the BDI overrides the Reset Configuration Words with the values provided."
Does anyone know if this means the BDI can override the RCW before the processor performs the \PORESET sequence? In other words, if I have and RCW line in the BDI configuration file, will it be able to provide RCW values to the proc essor when there are none present in the flash, and allow the \PORESET sequence to complete normally?
Thanks for any feedback.
Bruce
Bruce_Leonard@selinc.com wrote:
Does anyone know if this means the BDI can override the RCW before the processor performs the \PORESET sequence?
Yes. You use this feature to flash an RCW when the flash is trashed.
On Jun 15, 2007, at 2:13 PM, Timur Tabi wrote:
Yes. You use this feature to flash an RCW when the flash is trashed.
Technically, you don't "flash" an RCW, but rather provide one over the COP interface. :-) Also, remember that even if your flash (or eeprom, or whatever the location), has a valid RCW, the one provided by the BDI will be used if present in the configuration file.
-- Dan
Dan Malek wrote:
On Jun 15, 2007, at 2:13 PM, Timur Tabi wrote:
Yes. You use this feature to flash an RCW when the flash is trashed.
Technically, you don't "flash" an RCW, but rather provide one over the COP interface. :-)
What I meant is that you can use the BDI's RCW override feature to allow the CPU to be configured. Then you can configure the flash interface, and that will give you the ability to program flash. Then you "flash an RCW" (i.e. program the flash address that contain the RCW with a valid RCW).
What I meant is that you can use the BDI's RCW override feature to allow the CPU to be configured. Then you can configure the flash interface, and that will give you the ability to program flash. Then you "flash an RCW" (i.e. program the flash address that contain the RCW with a valid RCW).
You know, that's interesting. We're using a BDI2000 with an mpc8343 here, and have to set the processor to a pre-defined mode to initially flash a RCW in, then set it back to loading from local bus after we have a valid word programmed. We've followed Freescale's guides on how to connect the COP port to the CPU, but have never gotten past switching modes to program the RCW.
Quite interesting...
Best Regards,
Joe Grisso Synapse Product Development
Joe Grisso wrote:
You know, that's interesting. We're using a BDI2000 with an mpc8343 here, and have to set the processor to a pre-defined mode to initially flash a RCW in, then set it back to loading from local bus after we have a valid word programmed. We've followed Freescale's guides on how to connect the COP port to the CPU, but have never gotten past switching modes to program the RCW.
I'm not a hardware guy, so I can't tell you if you're doing something wrong or even if Freescale's guides (which I have not read) are complete.
I can say that I haven't had any real problems with the BDI-2000 on any Freescale reference board I've used. However, creating a BDI-2000 configuration file is tricky, especially if you're debugging U-Boot. U-Boot will generally not boot on a board that has had some BDI-2000 pre-programming (i.e. stuff in the [INIT] section). So I usually have two configuration files: one just for flashing, and the other for debugging early U-Boot.
The one for flashing will initialize the CPU, DDR, and flash memory.
In message 46783605.2070206@freescale.com you wrote:
I can say that I haven't had any real problems with the BDI-2000 on any Freescale reference board I've used. However, creating a BDI-2000 configuration file is tricky, especially if you're debugging U-Boot. U-Boot will generally not boot on a board that has had some BDI-2000 pre-programming (i.e. stuff in the [INIT] section). So I usually have
This is not correct. You just have to understand (and Reading the Fine Manual helps once more) the difference between "reset run" and "reset halt".
two configuration files: one just for flashing, and the other for debugging early U-Boot.
This is usually *not* necessary.
The one for flashing will initialize the CPU, DDR, and flash memory.
Just always use this configuration, and use "reset run" when you don't wan to run the init sequence.
Best regards,
Wolfgang Denk
Thanks for the responses. I was fairly sure it could be done, but we wanted to make sure.
Bruce
Timur Tabi timur@freescale.com wrote on 06/15/2007 02:13:45 PM:
Bruce_Leonard@selinc.com wrote:
Does anyone know if this means the BDI can override the RCW before the
processor performs the \PORESET sequence?
Yes. You use this feature to flash an RCW when the flash is trashed.
-- Timur Tabi Linux Kernel Developer @ Freescale
participants (5)
-
Bruce_Leonard＠selinc.com -
Dan Malek -
Joe Grisso -
Timur Tabi -
Wolfgang Denk