[U-Boot-Users] Re: Some puzzles on dram_size()
Hi Sam,
Your problem with dram_size() may be that it tests memory beyond the maxsize given.
for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) { addr = base + cnt; /* pointer arith! */
save[i++] = *addr; *addr = ~cnt; }
If maxsize = 16M, initial cnt = 4M, so if base = 0, the first time through the loop, addr = 16M which is the first address outside of the memory range given to test.
The reason it usually works is that most boards make the AM (address mask) in the OR (option register) of the memory controller specify more memory than they actually need.
This may be the easy way to fix it, however I would say the correct way would be to change the lines for (cnt = maxsize / sizeof (long); cnt > 0; cnt >>= 1) { for (cnt = 1; cnt <= maxsize / sizeof (long); cnt <<= 1) { to for (cnt = maxsize / sizeof (long) / 2; cnt > 0; cnt >>= 1) { for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
Unfortunately it appears in many board specific versions.
While I'm at it, the entire function should be moved to a file in the common directory and the function definition changed to long int dram_size (long int *base, long int maxsize)
The setting of the MxMR (memory A/B mode register) has nothing to do with determining the DRAM size and should be done in the calling function which is board specific.
I know, I'm free to submit a patch, but I'm a combination of busy and lazy.
Chris
Hi Chris,
in message OF5B21F0A5.A3EF40B7-ON85256E13.0056838C@nanometrics.ca you wrote:
Your problem with dram_size() may be that it tests memory beyond the maxsize given.
No. His max value as defined in the board config file was 64 MB, with an actual 16 MB of RAM. Accesses at 64 MB and 32 MB (= non-existend addresses) worked, but when accessing existing RAM at 16 MB he crashed.
The reason it usually works is that most boards make the AM (address mask) in the OR (option register) of the memory controller specify more memory than they actually need.
Let's put this right: the board config file is required to define SDRAM_MAX_SIZE greater than or equal to the maximum RAM size of the system.
This may be the easy way to fix it, however I would say the correct way would be to change the lines
This is not how the memory sizing algorithm is intended to work.
Unfortunately it appears in many board specific versions.
Not much longer. I will clean this up within the next few hours (or days).
While I'm at it, the entire function should be moved to a file in the common directory and the function definition changed to long int dram_size (long int *base, long int maxsize)
That's what I'll do.
Best regards,
Wolfgang Denk
Hi,Wolfgang,
--- Wolfgang Denk wd@denx.de wrote:
in message
OF5B21F0A5.A3EF40B7ON85256E13.0056838C@nanometrics.ca>
you wrote:
Your problem with dram_size() may be that it tests memory beyond the maxsize given.
No. His max value as defined in the board config file was 64 MB, with an actual 16 MB of RAM.
But there are two chips of MT48LC16M16A2 [2*(16*16/8)=64MByte] on LITE_DW.So set SDRAM_MAX_SIZE as 0x4000000 can match the need of SDRAM_MAX_SIZE.It should work but crashed.When I set SDRAM_MAX_SIZE as 0x2000000(32MB),it booted normally but the memory layout didn't look reasonable for u-boot located at high 128K of 32MB rather than high 128K of actual RAM.Followings are my test results on LITE_DW.
1.When I set SDRAM_MAX_SIZE as 0x2000000(32MB):
U-Boot 1.0.0 (Jan 7 2004 - 21:13:13)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: RPXlite DRAM: 32 MB FLASH: 16 MB *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: SCC ETHERNET u-boot>
But u-boot located at 0x01fe1000.And I could see 0x2000000-0x3ffffff.Meanwhile,it could load linux kernel and booted.
2.When I changed two lined code as Chris gave and set SDRAM_MAX_SIZE = 0x4000000(64MB),it worked well.
U-Boot 1.0.0 (Jan 7 2004 - 21:13:13)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: RPXlite DRAM: 64 MB FLASH: 16 MB *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial Net: SCC ETHERNET u-boot>
U-boot located at 0x03fe1000.
3.When I changed two lined code as Chris gave and set SDRAM_MAX_SIZE = 0x8000000(128MB),it worked badly.
U-Boot 1.0.0 (Jan 7 2004 - 21:22:40)
CPU: PPC823EZTnnB2 at 64 MHz: 16 kB I-Cache 8 kB D-Cache Board: RPXlite DRAM: Bus Fault @ 0xff012f4c, fixup 0x00000000 Machine check in kernel mode. NIP: 01FF1F88 XER: C000B25F LR: 03FE905C REGS: fa202bc0 TRAP: 1000 DAR: FF010F84 MSR: 00001002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 03FE9054 FA202CB0 00000000 03FF683C FA202B88 FA202B78 FFFFFFFE 00000000 GPR08: 00000001 00000000 FA202808 FA2011C8 00000000 00600000 FF020E00 04FE1000 GPR16: FFAC0085 00010001 00900104 40101D41 00001002 FA202CC8 00000000 03FE309C GPR24: 03FE9000 011C8402 00000001 00000007 FA200100 FA202EC0 04001F60 FA202CD8 Call backtrace: Software Emulation Exception NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
BDI>re - TARGET: processing user reset request - TARGET: resetting target passed - TARGET: processing target init list .... - TARGET: processing target init list passed BDI>g BDI>i Target state : running BDI>halt Target state : debug mode Debug entry cause : external breakpoint Current PC : 0x03ff5414 BDI>
My conclusion for the RAM-SIZE test code: 1. If the following word is the test code's purpose,the test code by now still need to fix.
Let's put this right: the board config file is required to define SDRAM_MAX_SIZE greater than or equal to the maximum RAM size of the system.
2. The RAM-SIZE test code of u-boot-1.0.0 in RPXlite.c can only work right when the setting of SDRAM_MAX_SIZE smaller than actual RAM but u-boot locates at high 128k of SDRAM_MAX_SIZE rather than high 128K of actual RAM.At least on LITE_DW,it work like this.
Best regards,
Sam Song
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message 20040107155938.24169.qmail@web15207.mail.bjs.yahoo.com you wrote:
- The RAM-SIZE test code of u-boot-1.0.0 in RPXlite.c
can only work right when the setting of SDRAM_MAX_SIZE
I'm not discussing any (probably broken) implementation of a specific board in 1.0.0. I was referring to the current _common_ implemetation_ for all boards that use such a function from the top of CVS (checked in _after_ 1.0.1).
Best regards,
Wolfgang Denk
Hi,Wolfgank,
Wolfgank wrote:
I'm not discussing any (probably broken) implementation of a specific board in 1.0.0. I was referring to the current _common_ implemetation_ for all boards that use such a function from the top of CVS (checked in _after_ 1.0.1).
Yeah,I tested the code from current CVS and it worked well when I set SDRAM_MAX_SIZE bigger than or same as actual RAM size.Thanks for your adjustment on the code.
Best regards,
Sam Song
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message OF5B21F0A5.A3EF40B7-ON85256E13.0056838C@nanometrics.ca you wrote:
While I'm at it, the entire function should be moved to a file in the common directory and the function definition changed to long int dram_size (long int *base, long int maxsize)
Done and checked in.
Best regards,
Wolfgang Denk
Hi,Chris,
--- chris@nanometrics.ca >
Hi Sam,
for (cnt = maxsize / sizeof (long) / 2; cnt > 0; cnt >>= 1) { for (cnt = 1; cnt < maxsize / sizeof (long); cnt <<= 1) {
I know, I'm free to submit a patch, but I'm a combination of busy and lazy.
Thanks for your "lazy" work.It does work basically.I tested these two lines on LITE_DW and ran well when SDRAM_MAX_SIZE equaled to the actual RAM size.A pity is that it cannot work while the setting of SDRAM_MAX_SIZE is bigger than the actual RAM.It seems that the RAM-SIZE test code still needs your patch.
Have a nice day!
Sam
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
In message 20040107151638.55077.qmail@web15204.mail.bjs.yahoo.com you wrote:
Thanks for your "lazy" work.It does work basically.I tested these two lines on LITE_DW and ran well when SDRAM_MAX_SIZE equaled to the actual RAM size.A pity is that it cannot work while the setting of SDRAM_MAX_SIZE is bigger than the actual RAM.It seems that the RAM-SIZE test code still needs your patch.
It works on all other boards. If you check out the current version of U-Boot from CVS you will find a common implementation for all boards. If it doesn't work for you, you probably have other problems.
Best regards,
Wolfgang Denk
participants (3)
-
chris＠nanometrics.ca -
SAM SONG -
Wolfgang Denk