[U-Boot-Users] Strange : Same 8248 image needs to be reprogrammed

[Jerry Van Baren]

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