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

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

[Sam Song]

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!!!

I wanna to blame it on config file we used or FLASH
programming mechanism or 8248 itself. But I have
no clear clue with them:-(

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

Thanks in advance,

Sam


		
___________________________________________________________
????G??????????????????
http://cn.mail.yahoo.com/?id=77072

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

[Sam Song]

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


	

	
		
___________________________________________________________ 
????G???????????????????
http://cn.mail.yahoo.com/?id=77071

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

[Jerry Van Baren]

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

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

[Sam Song]

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.

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

> 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?

> 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?

> 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?

Thanks a lot for your notes,

Sam


	

	
		
___________________________________________________________ 
????G???????????????????
http://cn.mail.yahoo.com/?id=77071

[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

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

[Sam Song]

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

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

[Jerry Van Baren]

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

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

[Sam Song]

Jerry Van Baren wrote:
[snip]
> 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

Really a nice hint to me, thanks!

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

Agree! This is the first choose for most of us:-)

Best regards,

Sam


	

	
		
___________________________________________________________ 
????G???????????????????
http://cn.mail.yahoo.com/?id=77071