[U-Boot-Users] Question about MPC8272 HRCW

[U-Boot-Users] Question about MPC8272 HRCW

[raymond yang]

Hello,

I am confused about the followin fields in HRCW,
MPC8272

CIP - 

0 MSR[IP]=1 (default), Exceptions are vectored to the
physical address 0xfffn_nnnn
1 MSR[IP]=0, Exceptions are vectored to the physical
address 0x000n_nnnn

BMS -

Boot memory space. Defines the initial value for
BR0[BA]. There are two possible bootmemory regions,
HIMEM and LOMEM
0 0xFE00_0000 -- 0xFFFF_FFFF
1 0x0000_0000 -- 0x1FFF_FFFF

My question:

1) Given BMS = 0
Does this mean, the FLASH(on CS0) are given the base
address as 0xFE00_0000? 

2) Given CIP = 0
Does this meman, the vector should be placed at
0xFFFn_nnnn?

So With BMS=0, and CIP=0, my flash should be bigger
than 
    0xFFFn_nnnn - 0xFE00_00000 >16M, right?

3) Given my flash is 8M byte, 16bit-bus-width, is it a
valid HRCW word for 08_82_32_45
My image got the following configurations
 MONITOR_BASE=TEXT_ADDR=0xFFF00000 
 CFG_FLASH_BASE = 0XFE800000


I tried many times, with BDI plugged, u-boot works
fine.
However, without BDI and RSTCN pull-up, looks like the
image never got run. 

Any ideas? Thanks ahead.

Best Regards
Raymond    

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

raymond yang <raymond_yang95134@yahoo.com> wrote:
> 1) Given BMS = 0
> Does this mean, the FLASH(on CS0) are given the base
> address as 0xFE00_0000? 

Not exactly. 0xFE00_0000 is just one of workable 
configuration.

> 2) Given CIP = 0
> Does this meman, the vector should be placed at
> 0xFFFn_nnnn?

Correct. This is HIGH BOOT location of 8272.

> So With BMS=0, and CIP=0, my flash should be bigger
> than 0xFFFn_nnnn - 0xFE00_00000 > 16M, right?

No. It just narrows your choose scope. If your FLASH
on board hasn't reached 32MByte, you can fit the whole
FLASH space in the setting scope as you like.

> 3) Given my flash is 8M byte, 16bit-bus-width, is it
> a valid HRCW word for 08_82_32_45
> My image got the following configurations
>  MONITOR_BASE=TEXT_ADDR=0xFFF00000 
>  CFG_FLASH_BASE = 0XFE800000

Seems good. But CFG_FLASH_BASE = 0xff800000 is also 
OK.

> I tried many times, with BDI plugged, u-boot works
> fine.However, without BDI and RSTCN pull-up, looks >
like the image never got run. 

Ummm, try to program the same image at 0xff800000
and pull down RSTCN to see what would happen:-)

Best regards,

Sam


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

[U-Boot-Users] Question about MPC8272 HRCW

[raymond yang]

Still have questions, thanks ahead!

According to DATASHEET

"BMS -

Boot memory space. Defines the initial value for
BR0[BA]. There are two possible bootmemory regions,
HIMEM and LOMEM
0 0xFE00_0000 -- 0xFFFF_FFFF
1 0x0000_0000 -- 0x1FFF_FFFF "

1) So if let BMS=0, 
-   Does this mean the BR0[BA] have the exact address
of 0xFE00_00000

or
-   Does this mean the BR0[BA] could be one of the
address between range 0XFE00_00000 and 0xFFFF_FFFFF,
if this is the case, so how can i determine the
specific value of BR0[BA]?

2)
With BMS=0 and CIP=0

According to the datasheet,

BR0[BA] = 0xFE00_0000 (Right?)
START_VECTOR = 0xFFF0_0100 

The span is START_VECTOR-BR0[BA] = 0xFFF0_0100 -
0xFE00_0000 = 0x1F00100 > 16M,
So if my flash is 8M bytes, i can't use this
configuration, right?

3)
I pull-down the RSTCONF, it doesn't work, only with
BDI2000 attached and config-file from BDI2000 (RSTCONF
up of cuz), U-BOOT can start correctly. 
I.e. 


Thanks ahead!

Best Regards
Raymond

 So With BMS=0, and CIP=0, my flash should be
> bigger
> > than 0xFFFn_nnnn - 0xFE00_00000 > 16M, right?
> 
> No. It just narrows your choose scope. If your FLASH
> on board hasn't reached 32MByte, you can fit the
> whole


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

> raymond yang <raymond_yang95134@yahoo.com> wrote:
> > 1) Given BMS = 0
> > Does this mean, the FLASH(on CS0) are given the
> base
> > address as 0xFE00_0000? 
> 
> Not exactly. 0xFE00_0000 is just one of workable 
> configuration.
> 
> > 2) Given CIP = 0
> > Does this meman, the vector should be placed at
> > 0xFFFn_nnnn?
> 
> Correct. This is HIGH BOOT location of 8272.
> 
> > So With BMS=0, and CIP=0, my flash should be
> bigger
> > than 0xFFFn_nnnn - 0xFE00_00000 > 16M, right?
> 
> No. It just narrows your choose scope. If your FLASH
> on board hasn't reached 32MByte, you can fit the
> whole
> FLASH space in the setting scope as you like.
> 
> > 3) Given my flash is 8M byte, 16bit-bus-width, is
> it
> > a valid HRCW word for 08_82_32_45
> > My image got the following configurations
> >  MONITOR_BASE=TEXT_ADDR=0xFFF00000 
> >  CFG_FLASH_BASE = 0XFE800000
> 
> Seems good. But CFG_FLASH_BASE = 0xff800000 is also 
> OK.
> 
> > I tried many times, with BDI plugged, u-boot works
> > fine.However, without BDI and RSTCN pull-up, looks
> >
> like the image never got run. 
> 
> Ummm, try to program the same image at 0xff800000
> and pull down RSTCN to see what would happen:-)
> 
> Best regards,
> 
> Sam
> 
> 
> 		
>
___________________________________________________________
> 
> ????????G??????No.1???????????????????? 
> http://cn.mail.yahoo.com/?id=77072
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

raymond yang <raymond_yang95134@yahoo.com> wrote:
> Boot memory space. Defines the initial value for
> BR0[BA]. There are two possible bootmemory regions,
> HIMEM and LOMEM
> 0 0xFE00_0000 -- 0xFFFF_FFFF
> 1 0x0000_0000 -- 0x1FFF_FFFF "
> 
> 1) So if let BMS=0, 
> -   Does this mean the BR0[BA] have the exact
> address of 0xFE00_00000

You need not to do it. BR0[BA] should accord with real
FLASH size while BMS just define boot memory space.
Note : boot memory space refers to the boot sector 
space should be. It does NOT mean the whole FLASH.

> 2)
> With BMS=0 and CIP=0
> 
> According to the datasheet,
> 
> BR0[BA] = 0xFE00_0000 (Right?)
> START_VECTOR = 0xFFF0_0100 
> 
> The span is START_VECTOR-BR0[BA] = 0xFFF0_0100 -
> 0xFE00_0000 = 0x1F00100 > 16M,
> So if my flash is 8M bytes, i can't use this
> configuration, right?

No. Just use it. No any problem to me. The fact
is that when you set BR0[BA] as 0xfe000000 the 
real flash 8MB will map to 32MB which is 
from 0xfe000000 to 0xfffffff. So the content of
0xfff00000 is the same as the one of 
0xfe700000/fef00000/ff700000. This is mirror theory:)

> 3)
> I pull-down the RSTCONF, it doesn't work, only with
> BDI2000 attached and config-file from BDI2000
> (RSTCONF
> up of cuz), U-BOOT can start correctly. 
> I.e. 

Seems the same problem I met. OK, just reprogram
the same image at 0xfff00000 again when RSTCONF pull
down and then disconnect BDI to power-on
to see what should happen:)

Best regards,

Sam


	

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

[U-Boot-Users] Question about MPC8272 HRCW

[Jerry Van Baren]

raymond yang wrote:
> Still have questions, thanks ahead!

[snip]

> 3)
> I pull-down the RSTCONF, it doesn't work, only with
> BDI2000 attached and config-file from BDI2000 (RSTCONF
> up of cuz), U-BOOT can start correctly. 
> I.e. 
> 
> 
> Thanks ahead!
> 
> Best Regards
> Raymond

Look in your BDI config file and see what the BDI initialization is 
doing that you are not doing the same.  The answer is in there.

One classic problem is that the BDI config is initializing SDRAM 
properly, but your code is not.  Another classic problem is that the BDI 
is initializing BR/OR registers that you've forgotten to do in your 
start up (or done too late in the start up).

Strip all but the bare essentials out of your BDI config file a piece at 
a time.  When it stops working with the BDI, you found either the 
problem or something essential for the BDI.  Your task is to determine 
which it is ;-).

gvb

[U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Raymond Yang writes:

    Raymond> Still have questions, thanks ahead!

    Raymond> According to DATASHEET

    Raymond> "BMS -

    Raymond> Boot memory space. Defines the initial value for
    Raymond> BR0[BA]. There are two possible bootmemory regions, HIMEM
    Raymond> and LOMEM 0 0xFE00_0000 -- 0xFFFF_FFFF 1 0x0000_0000 --
    Raymond> 0x1FFF_FFFF "

    Raymond> 1) So if let BMS=0,
    Raymond> - Does this mean the BR0[BA] have the exact address
    Raymond> of 0xFE00_00000

Immediately after reset - yes, this will be BR0 value. Then, in your
code, you can set it to whatever you wish.

    Raymond> or
    Raymond> - Does this mean the BR0[BA] could be one of the
    Raymond> address between range 0XFE00_00000 and 0xFFFF_FFFFF, if
    Raymond> this is the case, so how can i determine the specific value
    Raymond> of BR0[BA]?

    Raymond> 2) With BMS=0 and CIP=0

    Raymond> According to the datasheet,

    Raymond> BR0[BA] = 0xFE00_0000 (Right?)  START_VECTOR = 0xFFF0_0100

Yes.

    Raymond> The span is START_VECTOR-BR0[BA] = 0xFFF0_0100 -
    Raymond> 0xFE00_0000 = 0x1F00100 > 16M, So if my flash is 8M bytes,
    Raymond> i can't use this configuration, right?

Wrong, read again. You will see your flash in the last 8MB
(FF800000-FFFFFFFF). In fact, you will see it repeating itself four
times (FE000000 means 32MB address space).

    Raymond> 3) I pull-down the RSTCONF, it doesn't work, only with
    Raymond> BDI2000 attached and config-file from BDI2000 (RSTCONF up
    Raymond> of cuz), U-BOOT can start correctly. I.e.

For MONITOR_BASE=TEXT_ADDR=0xFFF00000 you need
CFG_FLASH_BASE=0xFF800000. Check BDI initialisations and set the HRCW to
get the same values.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
[snip]
> For MONITOR_BASE=TEXT_ADDR=0xFFF00000 you need
> CFG_FLASH_BASE=0xFF800000. Check BDI initialisations
> and set the HRCW to get the same values.

Really? Sounds CFG_FLASH_BASE=0xFE000000 is also OK
for HIGH BOOT situation. Am I right?

Thanks,

Sam

__________________________________________________
???????????????
http://cn.mail.yahoo.com

[U-Boot-Users] Question about MPC8272 HRCW

[Wolfgang Denk]

In message <17080.32989.840476.307428@astp0002.localdomain> you wrote:
>
...
>     Raymond> 0xFE00_0000 = 0x1F00100 > 16M, So if my flash is 8M bytes,
>     Raymond> i can't use this configuration, right?
> 
> Wrong, read again. You will see your flash in the last 8MB
> (FF800000-FFFFFFFF). In fact, you will see it repeating itself four
...
> For MONITOR_BASE=TEXT_ADDR=0xFFF00000 you need
> CFG_FLASH_BASE=0xFF800000. Check BDI initialisations and set the HRCW to


Actually I think that using  "CFG_FLASH_BASE=0xFF800000"  or  similar
for  a  high-boot configuration is not optimal, as it does not adjust
automatically for varying flash sizes.

Usually I use something like

	#define CFG_FLASH_BASE	(0-flash_info[0].size)

or even

	#define CFG_FLASH_BASE	(0-flash_info[0].size-flash_info[1].size)

in such cases.


Just an idea....

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
No, I'm not going to explain it. If you  can't  figure  it  out,  you
didn't want to know anyway... :-)
                   - Larry Wall in <1991Aug7.180856.2854@netlabs.com>

[U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Sam Song writes:

    Yuli> For MONITOR_BASE=TEXT_ADDR=0xFFF00000 you need
    Yuli> CFG_FLASH_BASE=0xFF800000. Check BDI initialisations and set
    Yuli> the HRCW to get the same values.

    Sam> Really? Sounds CFG_FLASH_BASE=0xFE000000 is also OK for HIGH
    Sam> BOOT situation. Am I right?

Generally speaking, it depends on the chip select initialisations. If
you set correct size (8MB in this case), TEXT_ADDR will not be mapped at
all with such CFG_FLASH_BASE=0xFE000000.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> Generally speaking, it depends on the chip select
> initialisations. If you set correct size (8MB in 
> this case), TEXT_ADDR will not be mapped at
> all with such CFG_FLASH_BASE=0xFE000000.

Ummm, I don't agree. If set BR0[BA] as FE00, u-boot
would know how to map TEXT_ADDR like FFF00000 at
physical address FE700000 in this case 8MB.

But I do aggree raymond to try 0xFF800000 as 
CFG_FLASH_BASE you suggested or the one wolfgang
mentioned:-)

Indeed, raymond should use LOW BOOT setting _rather
than_ use HIGH BOOT to splite 8MB flash to two part
for boot loader.

Thanks,

Sam


	

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

[U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Wolfgang Denk writes:

    Raymond> 0xFE00_0000 = 0x1F00100 > 16M, So if my flash is 8M bytes,
    Raymond> i can't use this configuration, right?

    Yuli> Wrong, read again. You will see your flash in the last 8MB
    Yuli> (FF800000-FFFFFFFF). In fact, you will see it repeating itself
    Yuli> four

    Yuli> For MONITOR_BASE=TEXT_ADDR=0xFFF00000 you need
    Yuli> CFG_FLASH_BASE=0xFF800000. Check BDI initialisations and set
    Yuli> the HRCW to

    Wolfgang> Actually I think that using "CFG_FLASH_BASE=0xFF800000" or
    Wolfgang> similar for a high-boot configuration is not optimal, as
    Wolfgang> it does not adjust automatically for varying flash sizes.

Using high-boot configuration on boards with flashes bigger than 1MB is
not optimal IMHO because it creates "hole" in the flash. I personally
can't see any reason to configure such boards for high-boot. I agree
that use of hard-coded values is inconvenient for varying flash sizes.

    Wolfgang> Usually I use something like

    Wolfgang> 	#define CFG_FLASH_BASE (0-flash_info[0].size)

    Wolfgang> or even

    Wolfgang> 	#define CFG_FLASH_BASE (0-flash_info[0].size-flash_info[1].size)

    Wolfgang> in such cases.

    Wolfgang> Just an idea....

The problem is that you usually have to specify BR0_PRELIM/OR0_PRELIM
which can't refer to variables like flash_info. You can initialise chip
selects in the flash driver if you write board-specific driver but if
you use common driver (CFI) things are more complicated.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Wolfgang Denk]

In message <17081.13579.857077.343042@astp0002.localdomain> you wrote:
> 
> Using high-boot configuration on boards with flashes bigger than 1MB is
> not optimal IMHO because it creates "hole" in the flash. I personally
> can't see any reason to configure such boards for high-boot. I agree

Agreed. Actually I don't see _any_ reason to configure  a  board  for
high-boot.

> The problem is that you usually have to specify BR0_PRELIM/OR0_PRELIM
> which can't refer to variables like flash_info. You can initialise chip
> selects in the flash driver if you write board-specific driver but if
> you use common driver (CFI) things are more complicated.

Yet another reason for me to use the CFI driver, umm, only occasionally.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't know if it's what you want, but it's what you get.  :-)
                      - Larry Wall in <10502@jpl-devvax.JPL.NASA.GOV>

[U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Sam Song writes:

    Yuli> Generally speaking, it depends on the chip select
    Yuli> initialisations. If you set correct size (8MB in this case),
    Yuli> TEXT_ADDR will not be mapped at all with such
    Yuli> CFG_FLASH_BASE=0xFE000000.

    Sam> Ummm, I don't agree. If set BR0[BA] as FE00, u-boot would know
    Sam> how to map TEXT_ADDR like FFF00000 at physical address FE700000
    Sam> in this case 8MB.

...

As I said, it depends on the chip select initialisations. If you set
BR0_PRELIM to 0xFExxxxxx and OR0_PRELIM to 0xFF8xxxxx, U-Boot will
crash.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Wolfgang Denk writes:

...

    Yuli> The problem is that you usually have to specify
    Yuli> BR0_PRELIM/OR0_PRELIM which can't refer to variables like
    Yuli> flash_info. You can initialise chip selects in the flash
    Yuli> driver if you write board-specific driver but if you use
    Yuli> common driver (CFI) things are more complicated.

    Wolfgang> Yet another reason for me to use the CFI driver, umm, only
    Wolfgang> occasionally.

Well, if a useful driver has problems, IMHO it's better to fix the
problems than to discard the driver:) I looked at many board-specific
flash drivers and many of them are clones containing all the bugs and
irrelevant code from the original versions. Of course, CFI driver needs
improvements and you've got several patches in the backlog with more
coming, but endless cloning of board-specific drivers IMHO is not a
better solution. When porting U-Boot to a new board, I find it very
useful to be able just to #define CONFIG_CFI instead of writing another
flash driver. Linux MTD handles it well and U-Boot driver is much
simpler than the Linux' one because it does not work in a multi-tasking
environment.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

--- Yuli Barcohen <yuli@arabellasw.com> wrote:
> As I said, it depends on the chip select
> initialisations. If you set
> BR0_PRELIM to 0xFExxxxxx and OR0_PRELIM to
> 0xFF8xxxxx, U-Boot will crash.

Oh, such configuration should lead to crash. But
how about OR0_PRELIM set to 0xFExxxxxx? All I want
to say is that BR0[BA] can set as 0xFE00 for 8MB
FLASH case. Yeah, some other related setting must
accord with it.

Thanks,

Sam



	

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

[spam] Re: [U-Boot-Users] Question about MPC8272 HRCW

[Yuli Barcohen]

>>>>> Sam Song writes:

    Yuli> As I said, it depends on the chip select initialisations. If
    Yuli> you set BR0_PRELIM to 0xFExxxxxx and OR0_PRELIM to 0xFF8xxxxx,
    Yuli> U-Boot will crash.

    Sam> Oh, such configuration should lead to crash. But how about
    Sam> OR0_PRELIM set to 0xFExxxxxx?

This would initialise 32MB address space, not 8MB. If you wish to map
more flash than you really have, do it. You will see the flash repeated
4 times. Not sure if CFI driver will work with it.

    Sam> All I want to say is that BR0[BA] can set as 0xFE00 for 8MB
    Sam> FLASH case. Yeah, some other related setting must accord with
    Sam> it.

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================

[U-Boot-Users] Question about MPC8272 HRCW

[Sam Song]

--- Wolfgang Denk <wd@denx.de> wrote:
> flash. I personally
> > can't see any reason to configure such boards for
> > high-boot. I agree
> 
> Agreed. Actually I don't see _any_ reason to
> configure  a  board  for high-boot.

Perhaps one situation should use high-boot. If
RSTCONF pull up always or first sector of FLASH
was damaged accidentally, high-boot can make
the board work although some performance would
lost in this default configuration.

Have you tried the default configuration? I once
did it on a 8248 board but in vain and
wanna to know whether there is some special thing 
with it. Well, I confess that there was a 100MHz
CLKIN which was bigger than 60-80MHz UM limited.
Is this the case?

Thanks,

Sam


		
___________________________________________________________ 
???????????2G?????pop3?????????? 
http://cn.mail.yahoo.com/mail_alert/promo1.html