Sam Song wrote:
Jerry Van Baren wrote:
Confusion issues:
RSTCONF* is active low so either a) you are pulling it down, not up b) you have an inverter buffering it c) are wrong (since you can program flash, this is unlikely)
Sure. Sth confused on RSTCONF#. Seems we should clarify the meaning of RSTCONF# first. I have no inverter buffering on RSTCONF#.
When I say pull up RSTCONF#, i.e., deassert RSTCONF#, target will use the default value 0x00000000 as HRCW. At this time, 8248 doesn't get the HRCW from FLASH. Although the default value 0x00000000 isn't the expected, we can connect WireTAP or BDI to reset the target and program FLASH on board.
By contraries, if RSTCONF# is pulled down, i.e., assert RSTCONF#, 8248 does get the value from FLASH. At this time, if the FLASH content is 0xFFFFFFFF, 8248 core will stop work and even JTAG like WireTAP cannot reset the target.
I got the above view from UM 5-1 ~ 5-13 Part II and my practice.
[snip]
High boot: With RSTCONF* asserted, you can program any of flash anywhere, so you could theoretically program the HRCW and u-boot in the same programming session (two programming operations). Since the default HRCW when RSTCONF* is asserted sets the ISB to 0x0000_0000, if
Ummm, I found out the confusion coming from. Jerry, you thought the default HRCW value 0x000000 was due to RSTCONF# assertion(RSTCONF# pull low). Seems you inverted the view on default HRCW value.
UM on line 11 P5-8 says, In a simple system that uses one stand-alone MPC8272, it is possible to use the default hard reset configuration words(all zeros). This is done by tying RSTCONF# input to VCC.
My bad. Indeed, I had the effect of RSTCONF* backwards: as you say, pulling it down causes a fetch of the HRCW from flash while pulling it up causes the default 0x00000000 to be used. Sorry.
[snip]
If inverted your RSTCONF# description, I come to find out several key point on BDI and a BRAND-NEW 8260 serial target:
- Low boot image programming : Deassert RSTCONF#,
program u-boot, assert RSTCONF#, cycle power. Simple.
OK, it's time for me to blame the reprogram strange things on WireTAP including it's config file. To program a boot-low image with WireTAP, H/W guy guides me pull up and down RSTCONF# with two different config files and reprogram the same image at the same location. There MUST sth needs improvement.
Thanks again for your kind help,
Sam
Glad to help you shift the blame ;-), sorry about the confusion. FWIIW, with the BDI2000 I need to use a different config file when I program an erased (new) boot flash chip. The reason for this is because the IMMR for the default HRCW (ISB) is at location 0x00000000. The first thing I do in the config file is to move the IMMR to the "proper" place, after which all the other initialization is fine because the IMMR is in the same place. In "BDI2000 speak", WM32 is a 32 bit memory write, and the following writes the IMMR register where it currently resides, programming it to go to the proper location.
RSTCONF* deasserted (virgin/erased flash): WM32 0x000101A8 0xF0000000 ; IMMR -> where we want it
RSTCONF* asserted (low) - this actually is a "NOP" but reminds me that this is important and why when I try to use this config file to program a virgin flash ;-). WM32 0xF00101A8 0xF0000000 ; IMMR -> where we want it
This reminded me, my recipe needs another step to switch to your special "RSTCONF* deasserted" BDI2000/WireTAP config before programming u-boot.
Programming u-boot is easier if you are using boot-low since one shot programs it all.
If you are booting "high", you will need two programming operations, the first being the HRCW at the first offsets of flash and the second to put u-boot in. Note that it is pretty trivial to create a short s-record file with just the HRCW (the easiest approach is to cut the first couple of lines out of u-boot, but you will need to offset it properly, typically via your WireTAP program command). Since the HRCW is pretty constant, this isn't a big deal, but IMHO it is much easier, safer, and better to use boot-low... but I'm preaching to the choir ;-).
gvb