Sam Song wrote:

--- Sam Song samsongshu@yahoo.com.cn wrote:

...

Hi all,

After porting u-boot on a 8248 board, I was confused

by a programming problem with WireTAP. For the sake of 8248/8260 HRCW theory, RSTCONF must pull up to connect 8248 target with a No-head config file when there is a blank FLASH on board or WireTAP cannot init the target correctly. The programming process is as follows:

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!

We suspected sth wrong on first programmig. So we checked the FLASH content with WireTAP but found at least first and last three bytes had the right content. Should I need to check all FLASH content? The image I compiled first is about 100KByte!!!

Ummm, a little improvement. I finally found out the problem was due to first program itself. The new flash with first config file could only be programmed with a limited sector.

Programmed part location: 0x0 - 0x800; 0x10000 - 0x10800; 0x20000 - 0x20800.

Seems 2KB in every 64KB area was programmed when RSTCONF pulls up. Still a strang phenomenon to me:-)

...

Could anyone have similar experience on 8260 series target? How about BDI2000 on it? Any idea?

If anyone share their experience on BDI would be a great help.

Thanks,

Sam

The reason your first approach didn't work is because the HRCW gets read from the _first_32_bytes_ of flash (four reads at offsets 0, 8, 16, 24 with CS0 asserted). It isn't read from any true "address" - BR0/OR0 are configured by the HRCW and thus cannot be used for reading the HRCW. When you programmed u-boot at 0xFFF00000, u-boot was programmed into the proper location but the HRCW got programmed into the top part of your flash device, _not_ the first 32 bytes. When you programmed u-boot at 0xFF000000, you got the HRCW in the right place but not u-boot (but that was OK because you programmed it in the right place previously).

This is another reason for doing "low-boot" rather than "high-boot": in "low-boot" mode, both u-boot and the HRCW get placed in the proper memory locations inherently.

Answering your second question, my experience is that RSTCONF is necessary and _barely_ sufficient to program the HRCW in the first 32 bytes of flash. I never try to do more than that. Once you have a valid HRCW programmed, deassert RSTCONF, cycle power (IMPORTANT since the HRCW is only read on a full reset) and proceed normally.

gvb

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)

Do you intend to boot high or low normally? I'm assuming boot-high (and would recommend you switch to 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.

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]

...

The reason your first approach didn't work is because the HRCW gets read from the _first_32_bytes_ of flash (four reads at offsets 0,

In my first programming, RSTCONF pull up, HRCW is the default vaule 0x00000000. It doesn't need to read it from FLASH at all.

When you programmed at 0xff000000, you put the HRCW in the right place but u-boot in the wrong place for boot-high. Both are in the right place for boot-low. I cannot explain why programming a second time at 0xff000000 "fixed" it, I would speculate that you really programmed at 0xfff00000 which would put u-boot in the right place for boot-high.

...

8, 16, 24 with CS0 asserted). It isn't read from any true "address" - BR0/OR0 are configured by the HRCW and thus cannot be used for reading the HRCW.

Yeah, I do agree. In

...

When you programmed u-boot at 0xFFF00000, u-boot was programmed into the proper location but the HRCW

I didn't program u-boot on 0xFFF00000 in this case. 0xFF000000 instead.

As noted above, this doesn't make sense.

...

This is another reason for doing "low-boot" rather than "high-boot": in "low-boot" mode, both u-boot and the HRCW get placed in the proper memory locations inherently.

Yeah, thanks to the perfect adjustment on 8260, all we can do is to program one image at the first sector of FLASH to finish HRCW and boot the target at the same time. Low boot is much better than high boot on this point.

...

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).

...

to program the HRCW in the first 32 bytes of flash. I never try to do more than that.

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).

There is one minor advantage of boot-low: you can replace u-boot without erasing and re-programming the HRCW. With boot-high, if you mess up reprogramming u-boot (and, inherently, the HRCW), you need to put the RSTCONF* jumper on, recover the HRCW, pull the RSTCONF* jumper off. With boot-low, you would only mess up u-boot, not the HRCW, so recovery doesn't include messing with the RSTCONF* jumpper. Like I said, basically no advantage.

...

Once you have a valid HRCW programmed, deassert RSTCONF, cycle power (IMPORTANT since the HRCW is only read on a full reset) and proceed normally.

Uh, Does "proceed normally" here mean we can use BDI to program the low-boot image at the first sector of FLASH? If so, BDI also needs to reprogram the low-boot image at the first sector of FLASH.

Or "proceed normally" means the programmed target can boot directly with the image which was done by pull-up case?

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.

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 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 memory map will be what you normally run with and things will be a lot less confusing.

Thanks a lot for your notes,

Sam

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