[U-Boot] problem with mpc837x start.S
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
Thanks, Scott. I thought no one would reply to this question. ----------------------------------------
Date: Mon, 1 Aug 2011 13:48:22 -0500 From: scottwood@freescale.com To: programassem@hotmail.com CC: u-boot@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
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
----------------------------------------
Date: Tue, 2 Aug 2011 10:21:09 -0500 From: scottwood@freescale.com To: programassem@hotmail.com CC: u-boot@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
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@freescale.com To: programassem@hotmail.com CC: u-boot@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
Date: Wed, 3 Aug 2011 10:48:39 -0500 From: scottwood@freescale.com To: programassem@hotmail.com CC: u-boot@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@freescale.com To: programassem@hotmail.com CC: u-boot@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
----------------------------------------
From: programassem@hotmail.com To: scottwood@freescale.com CC: u-boot@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@freescale.com To: programassem@hotmail.com CC: u-boot@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@freescale.com To: programassem@hotmail.com CC: u-boot@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
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
Thanks, Scott.
-Shawn
----------------------------------------
Date: Mon, 8 Aug 2011 15:42:38 -0500 From: scottwood@freescale.com To: programassem@hotmail.com CC: u-boot@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
participants (2)
-
Scott Wood -
shawn Bai