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.
Do you intend to boot high or low normally? I'm assuming boot-high (and would recommend you switch to boot-low).
I prefer to boot-low and has been talking with you boot-low.
Note: you probably cannot avoid setting the BR0 and OR0 registers as part of your BDI initialization because the default HRCW is all zeros which is probably _not_ right for your hardware (BPS => 64 bit port size, BMS => 0xFE00_000). You should verify that your WireTAP configuration has the necessary and sufficient initialization and (preferably) no more.
I really appreciate this hint. Some more check should be done on init config file of WireTAP. I also got the key point from your feedback. So glad to know BDI only programs the boot-low image once on 8260 serial target.
Sam Song wrote:
Jerry Van Baren wrote:
Pull up RSTCONF -> Connect WireTAP with No-head config file -> Program the image on 0xff000000 -> Disconnect WireTAP -> Pull down RSTCONF -> Power-on -> No serial output -> Power-down -> Connect WireTAP with head config file -> Reprogram the same image at 0xff000000 -> Disconnect WireTAP -> Power-on -> Work!
[snip]
Answering your second question, my experience is that RSTCONF is necessary and _barely_ sufficient
So you mean RSTCONF MUST pull up when programming a blank FLASH on a 8260 target with BDI?
It must be _active_ (the physical pin must be pulled low, your hardware may be inverting it). A blank flash will be 0xffffffff which is not a valid HRCW and you will _not_ be able to program flash (CDIS core disable probably causes this).
Seems one of us has a problem on understanding the relationship between HRCW and RSTCONF#. To my understanding, if RSTCONF# is _active_(the physical pin is pulled low), 8248 will get HRCW from FLASH. So a blank FLASH value 0xFFFFFFFF will lead 8248 core to a disable status. A JTAG tool like WireTAP cannot init the target properly. FLASH programming is impossible to be done in this case.
My knowledge and experience is that RSTCONF# MUST pull up to init a blank FLASH target with WireTAP.
So for every brand-new target, we need to pullup RSTCONF once for programming the HRCW. Right?
Could we program the low-boot image at this time once for all on BDI?
Yes (RSTCONF* active) and yes. The two big advantages of boot-low are 1a) No awkward flash size-dependent gap between the HRCW and u-boot 1b) You cannot use any of the other bytes in the first sector of flash for write purposes (which includes env variables) without risking screwing up your HRCW and turning the unit into a brick at your customer's site (big points off). This means you either waste most of the sector or you find something that doesn't ever change to put in the first sector. 2) One program operation with no offsets programs everything necessary to boot (u-boot + HRCW).
I am so glag to know that BDI can finish the image programming only once on a BRAND-NEW target when RSTCONF# is _active_(RSTCONF# is pulled low).
[snip]
Low boot: one program of the u-boot image takes care of both the HRCW and u-boot. Assert RSTCONF*, program u-boot, deassert RSTCONF*, cycle power. Simple.
Confusion here:-). Why deassert RSTCONF* ??? This would make target to a boot-high status. boot-low needs RSTCONF# assert when power-on!!!
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.
you link u-boot to reside at 0xFFF00000, you will have to use the proper offset on your BDI command to put the u-boot image in the top 1MB of flash (flash size dependent). I find it is much easier to program the HRCW so that my memory map is what it should be, deassert RSTCONF*, and cycle power to pick up the HRCW. At this point, you
Again, I got your inverted view on RSTCONF# meaning.
memory map will be what you normally run with and things will be a lot less confusing.
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
__________________________________________________ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com