[U-Boot] problem with mpc837x start.S

shawn Bai programassem at hotmail.com
Mon Aug 8 10:29:22 CEST 2011




----------------------------------------
> From: programassem at hotmail.com
> To: scottwood at freescale.com
> CC: u-boot at lists.denx.de
> Subject: RE: [U-Boot] problem with mpc837x start.S
> Date: Thu, 4 Aug 2011 11:37:02 +0000
>
>
>
>
>
> > Date: Wed, 3 Aug 2011 10:48:39 -0500
> > From: scottwood at freescale.com
> > To: programassem at hotmail.com
> > CC: u-boot at lists.denx.de
> > Subject: Re: [U-Boot] problem with mpc837x start.S
> >
> > On Wed, 3 Aug 2011 00:48:32 +0000
> > shawn Bai <programassem at hotmail.com> wrote:
> >
> > > ----------------------------------------
> > > > Date: Tue, 2 Aug 2011 10:21:09 -0500
> > > > From: scottwood at freescale.com
> > > > To: programassem at hotmail.com
> > > > CC: u-boot at lists.denx.de
> > > > Subject: Re: [U-Boot] problem with mpc837x start.S
> > > >
> > > > On Tue, 2 Aug 2011 04:11:25 +0000
> > > > shawn Bai <programassem at hotmail.com> wrote:
> > > >
> > > > > > When flash is enlarged to 4GiB, it repeats throughout the address space.
> > > > >
> > > > > After flash is enlarged to 4GiB, why will it repeat through the address space? the whole 4GiB address space?How does it happen?
> > > >
> > > > It's just how the hardware works -- the flash chip only sees the address
> > > > bits that are relevant to its size. The higher address lines can be
> > > There must be something needed to learnt by myself to understand "how the hardware works".
> > > And, when you mention "its size", you mean 8MBytes,or 4GiB?
> >
> > If the flash is 8MiB (as determined by physical reality, not OR0), it only
> > decodes the low 23 bits of the address. The upper bits must hit in BR0/OR0,
> > but after that they are discarded. So for example, if OR0 maps a 4GiB
> > window, 0x00123456, 0x00923456, 0xff123456, and 0xe0123456 all point to the
> > same location in flash, because the flash only sees 0x123456.
> >
> > -Scott
>
>
>
> When enlarging Nor Flash to 4GiB, the AM in OR0 is 0x0000_0, where the number of zero is 17.
>
> According to what is said in datasheet, if the bit value of some bit in address mask is 0,
> then the corresponding bit in address will be masked.
>
> So, the higher 17 bits in address will be masked, is it right ?
>
> If so, the range accessed in flash is just 32KBytes from the BA in BR0.
> Is that right ? But Not the same with what you mean.
>
> And from what you replied before in this question, may I say the 32KBytes will repeat through 4GiB address space ? not 8MBytes ?
>
> And with the effect of address mask in OR, as you say above, the higher bits is masked.
> Now, we go back to CONFIG_SYS_MONITOR_BASE + in_flash, whatever value of the sum is, higher of it will be masked,
>
> so the label 'in_flash' will be located in flash, that is,
> both "in_flash" and "CONFIG_SYS_MONITOR_BASE + in_flash" can locate at where in_flash is in flash.
>
> Even branching to location CONFIG_SYS_MONITOR_BASE + in_flash, it's the instruction that locates at "in_flash" to be run.
>
> then, what is the effect of CONFIG_SYS_MONITOR_BASE in this ABSOLUTE branch as uboot comment indicates ?
>
> Thanks.
>
> -Shawn
>
Hello,  Scott, are you there? 
Or is there anyone else who can help me With this question?
I become confused...
Come on, guys.
-Shawn

> >
 		 	   		  


More information about the U-Boot mailing list