[U-Boot-Users] Question about MPC8272 HRCW
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
raymond yang raymond_yang95134@yahoo.com wrote:
- 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.
- 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.
- 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
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:
- 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.
- 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.
- 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
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 "
- 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.
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:)
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
raymond yang wrote:
Still have questions, thanks ahead!
[snip]
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
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 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
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 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
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 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
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.
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
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.
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
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.
--- 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
participants (5)
-
Jerry Van Baren -
raymond yang -
Sam Song -
Wolfgang Denk -
Yuli Barcohen