[U-Boot] problem with mpc837x start.S

[U-Boot] problem with mpc837x start.S

[shawn Bai]

Hello, boys and girls, my name is shawn Bai. I am new here and hope not disturb you.
Although I have not posted before, what you do is very helpful to me to understand what is bsp, how it runs, and so on.
I don't know whether the question below is mentioned or not before.
If yes, do you mind telling me where I can find the answer.
Thanks in advance.

The question is about arch\powerpc\cpu\83xx\start.S.
the demo board I use is MPC837xERDB, there is 8MBytes Nor flash on it.
by default, uboot is booted from lower address, it means BMS field in HRCW is 0, which will affect value of MSR[IP] later.
First instruction locates at _start label in uboot.
Before first instruction runs, hardware reset configuration word will be loaded to make some basic configuration.
Before branching to MONITOR_BASE+in_flash using blr instruction? size of LCS0 is inflated to 4GBytes?
and eLBC access window 1 is configured with BAR MONITOR_BASE, and SIZE 8MBytes.
After this is done, blr to MONITOR_BASE+in_flash.
after branching to MONITOR_BASE+in_flash, LCS0 BAR is modified to MONITOR_BASE, and its size is configured with 8Mbytes again.
This is what I know.
But the problem which is confused to me is
after reset, the default value of LCS0 BAR is 0x0000_0000, and its size is 8Mbytes.
In order to branch to MONITOR_BASE+in_flash, inlarge Nor flash to 4GB, and configure eLBC access window 1. 
But the actual size of Nor flash is 8MB , even after inlarging it, where (MONITOR_BASE+in_flash) points to? why?
why does branching to in_flash need absolute address? and make absolute address like this?
I rack my brains, but there is no result.
Do you mind showing me a way?
Thanks very much.
 
Shawn Bai

>
> ------------------------------
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
> ************************************** 		 	   		  

[U-Boot] problem with mpc837x start.S

[shawn Bai]

Sorry, guys,
I have no idea whether it makes you feel uncomfortable the way I ask questions.
If yes? I apologize.
But, I really don't understand the way uboot branch to nor flash, branch to ram.
I have read the source code in the 83xx/start.S file for many times,
and I have looked up the archives of uboot mailinglist in Dec. 2010.
I found that the way start.S is written is for position independent code.
I really know little with this kind of impelmentation.
Is there anyone who is willing to give some guidance, such as website?
Thanks a lot.
Best Regards,
Shawn

----------------------------------------
> From: programassem at hotmail.com
> To: u-boot at lists.denx.de
> Subject: problem with mpc837x start.S
> Date: Wed, 27 Jul 2011 06:21:13 +0000
>
>
> Hello, boys and girls, my name is shawn Bai. I am new here and hope not disturb you.
> Although I have not posted before, what you do is very helpful to me to understand what is bsp, how it runs, and so on.
> I don't know whether the question below is mentioned or not before.
> If yes, do you mind telling me where I can find the answer.
> Thanks in advance.
>
> The question is about arch\powerpc\cpu\83xx\start.S.
> the demo board I use is MPC837xERDB, there is 8MBytes Nor flash on it.
> by default, uboot is booted from lower address, it means BMS field in HRCW is 0, which will affect value of MSR[IP] later.
> First instruction locates at _start label in uboot.
> Before first instruction runs, hardware reset configuration word will be loaded to make some basic configuration.
> Before branching to MONITOR_BASE+in_flash using blr instruction? size of LCS0 is inflated to 4GBytes?
> and eLBC access window 1 is configured with BAR MONITOR_BASE, and SIZE 8MBytes.
> After this is done, blr to MONITOR_BASE+in_flash.
> after branching to MONITOR_BASE+in_flash, LCS0 BAR is modified to MONITOR_BASE, and its size is configured with 8Mbytes again.
> This is what I know.
> But the problem which is confused to me is
> after reset, the default value of LCS0 BAR is 0x0000_0000, and its size is 8Mbytes.
> In order to branch to MONITOR_BASE+in_flash, inlarge Nor flash to 4GB, and configure eLBC access window 1.
> But the actual size of Nor flash is 8MB , even after inlarging it, where (MONITOR_BASE+in_flash) points to? why?
> why does branching to in_flash need absolute address? and make absolute address like this?
> I rack my brains, but there is no result.
> Do you mind showing me a way?
> Thanks very much.
>
> Shawn Bai
>
> >
> > ------------------------------
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
> >
> > **************************************

 		 	   		  

[U-Boot] problem with mpc837x start.S

[Scott Wood]

On Wed, 27 Jul 2011 06:21:13 +0000
shawn Bai <programassem@hotmail.com> wrote:

> The question is about arch\powerpc\cpu\83xx\start.S.
> the demo board I use is MPC837xERDB, there is 8MBytes Nor flash on it.
> by default, uboot is booted from lower address, it means BMS field in HRCW is 0, which will affect value of MSR[IP] later.
> First instruction locates at _start label in uboot.
> Before first instruction runs, hardware reset configuration word will be loaded to make some basic configuration.
> Before branching to MONITOR_BASE+in_flash using blr instruction? size of LCS0 is inflated to 4GBytes?
> and eLBC access window 1 is configured with BAR MONITOR_BASE, and SIZE 8MBytes.
> After this is done, blr to MONITOR_BASE+in_flash.
> after branching to MONITOR_BASE+in_flash, LCS0 BAR is modified to MONITOR_BASE, and its size is configured with 8Mbytes again.
> This is what I know.
> But the problem which is confused to me is
> after reset, the default value of LCS0 BAR is 0x0000_0000, and its size is 8Mbytes.
> In order to branch to MONITOR_BASE+in_flash, inlarge Nor flash to 4GB, and configure eLBC access window 1. 
> But the actual size of Nor flash is 8MB , even after inlarging it, where (MONITOR_BASE+in_flash) points to? why?
> why does branching to in_flash need absolute address? and make absolute address like this?

When flash is enlarged to 4GiB, it repeats throughout the address space.
We branch to the absolute address because that's where flash is going to
end up after it's shrunk to its normal size.

-Scott

[U-Boot] problem with mpc837x start.S

[shawn Bai]

Thanks, Scott. I thought no one would reply to this question.
----------------------------------------
> Date: Mon, 1 Aug 2011 13:48:22 -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, 27 Jul 2011 06:21:13 +0000
> shawn Bai <programassem@hotmail.com> wrote:
>
> > The question is about arch\powerpc\cpu\83xx\start.S.
> > the demo board I use is MPC837xERDB, there is 8MBytes Nor flash on it.
> > by default, uboot is booted from lower address, it means BMS field in HRCW is 0, which will affect value of MSR[IP] later.
> > First instruction locates at _start label in uboot.
> > Before first instruction runs, hardware reset configuration word will be loaded to make some basic configuration.
> > Before branching to MONITOR_BASE+in_flash using blr instruction? size of LCS0 is inflated to 4GBytes?
> > and eLBC access window 1 is configured with BAR MONITOR_BASE, and SIZE 8MBytes.
> > After this is done, blr to MONITOR_BASE+in_flash.
> > after branching to MONITOR_BASE+in_flash, LCS0 BAR is modified to MONITOR_BASE, and its size is configured with 8Mbytes again.
> > This is what I know.
> > But the problem which is confused to me is
> > after reset, the default value of LCS0 BAR is 0x0000_0000, and its size is 8Mbytes.
> > In order to branch to MONITOR_BASE+in_flash, inlarge Nor flash to 4GB, and configure eLBC access window 1.
> > But the actual size of Nor flash is 8MB , even after inlarging it, where (MONITOR_BASE+in_flash) points to? why?
> > why does branching to in_flash need absolute address? and make absolute address like this?
>
> 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 must be very easy to understand.But, sorry, I cannot catch the main point.Could you go into some details?


> We branch to the absolute address because that's where flash is going to
> end up after it's shrunk to its normal size.
>
> -Scott
>


 		 	   		  

[U-Boot] problem with mpc837x start.S

[Scott Wood]

On Tue, 2 Aug 2011 04:11:25 +0000
shawn Bai <programassem@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
anything, as long as they cause the transaction to be routed to the
flash chip.

-Scott

[U-Boot] problem with mpc837x start.S

[shawn Bai]

----------------------------------------
> 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@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?
I cannot turn the corner at this moment.
-Shawn

> anything, as long as they cause the transaction to be routed to the
> flash chip.
>
> -Scott
>
 		 	   		  

[U-Boot] problem with mpc837x start.S

[Scott Wood]

On Wed, 3 Aug 2011 00:48:32 +0000
shawn Bai <programassem@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@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

[U-Boot] problem with mpc837x start.S

[shawn Bai]

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

>  		 	   		  

[U-Boot] problem with mpc837x start.S

[shawn Bai]

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

> >
 		 	   		  

[U-Boot] problem with mpc837x start.S

[Scott Wood]

On 08/04/2011 06:37 AM, shawn Bai wrote:
> 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.

The address mask applies only to matching a chip select.  Once it's been
matched, the full address goes to the device -- minus the bits that the
device does not implement.  An bit whose address mask is zero is treated
the same as the least-significant 15 bits.

> And from what you replied before in this question, may I say the 32KBytes will repeat through 4GiB address space ? not 8MBytes ?

No.

> then, what is the effect of CONFIG_SYS_MONITOR_BASE in this ABSOLUTE branch as uboot comment indicates ?

The effect is that the program counter contains "CONFIG_SYS_MONITOR_BASE
+ in_flash", so that when the code later shrinks the chipselect it will
still be executing from flash.

-Scott

[U-Boot] problem with mpc837x start.S

[shawn Bai]

 
Thanks, Scott.
 
-Shawn

----------------------------------------
> Date: Mon, 8 Aug 2011 15:42:38 -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 08/04/2011 06:37 AM, shawn Bai wrote:
> > 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.
>
> The address mask applies only to matching a chip select. Once it's been
> matched, the full address goes to the device -- minus the bits that the
> device does not implement. An bit whose address mask is zero is treated
> the same as the least-significant 15 bits.
>
> > And from what you replied before in this question, may I say the 32KBytes will repeat through 4GiB address space ? not 8MBytes ?
>
> No.
>
> > then, what is the effect of CONFIG_SYS_MONITOR_BASE in this ABSOLUTE branch as uboot comment indicates ?
>
> The effect is that the program counter contains "CONFIG_SYS_MONITOR_BASE
> + in_flash", so that when the code later shrinks the chipselect it will
> still be executing from flash.
>
> -Scott
>