About the SDRAM SIZE CONFIGURATION OF MCF5372L

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

About the SDRAM SIZE CONFIGURATION OF MCF5372L

1,979 Views
ccd306
Contributor I

I am developing a products based on MCF5372L.

And I found that when I configure the SDRAM size as 64MBYTES in KERNEL, it is much more slower than setting SDRAM SIZE as 32MBYTES. I don’t know why. Could some guy tell me how to debug this issue? And the attachement is the print information when power on.

Thanks.

Labels (1)
0 Kudos
20 Replies

1,396 Views
ccd306
Contributor I

How can I read the value of CACR,ACR0 and ACR1?

Could you send me an example?

0 Kudos

1,396 Views
TomE
Specialist II

Accessing those registers requires small assembly functions that you then need to link into your program.

 

These registers are *WRITE ONLY*. They can't be read from the CPU. They can be read from a debug pod (apparently). Check the Cache section in the Manual.

 

Except that since you're running under Linux, your user code is probably running at "User Level' and you probably can't get to these registers in that mode anyway.

 

So it needs "kernel level" code to do that.

 

But forget all that, simply search *ALL* of the source code for matches on "CACR", "ACR0" and "ACR1". When you find where the code accesses those registers you should be able to see what it is using (for the addresses and size) and then find where the variables/constants it is using are set.

 

That might also find you example code showing how to access these. The usual way is a library of assembly code with standard names that is then accessed from C code. Functions with names like:

 

void mcf5xxx_wr_cacr(uint32_t);
void mcf5xxx_wr_acr0(uint32_t);
void mcf5xxx_wr_acr1(uint32_t);
void mcf5xxx_wr_acr2(uint32_t);

 

These are defined in the file "mcf5xxx.S" file in my code base 9which isn't uClinux though, YMMV).

 

Have you read the documentation on how to configure uClinux?

 

Tom

 

0 Kudos

1,396 Views
TomE
Specialist II

Earlier you wrote:

> So the firmware is composed of Bootloader,FPGA,Kernel , Application and FileSystem

 

Check the Bootloader first. It may be responsible for writing to these registers. It certainly has to be responsible for programming the SDRAM controller for the right amount of memory. It is likely that the lines of code (and preferably "#defines", but possibly raw hex data) that sets up the SDRAM controller isn't "linked" to the code that programs the Cache and the ACL registers. They should be working from a common set of definitions, but may not be.

 

Tom

 

0 Kudos

1,396 Views
ccd306
Contributor I

I find the Cache and SDRAM configuration. I try to debug it. But it  still does not work well.

Can you send me the sample codes of Bootloader including 64M SDRAM configuration?

0 Kudos

1,396 Views
TomE
Specialist II

> Can you send me the sample codes of Bootloader including 64M SDRAM configuration?

 

No, because I have no idea what bootloader you're running, and don't want to know. Don't send any sources as I won't read them (unless limited to 10 or so relevant lines and included in-line in the post).

 

The Cache chapter of the Reference Manual provides plenty of details of the "Address Base" and "Address Mask" fields of the ACR registers for you to work out what they should be set to.

 

If the problem is the configuration of the boot loader (to get the right numbers into those registers), then if it is U-Boot then read all the documentation on how to configure it and check the U-Boot forums. If it is a uCLinux configuration, then documentation and forums for that product.

 

> I find the Cache and SDRAM configuration. I try to debug it.

 

I can't see your code from here. Why don't you cut-paste a VERY SMALL sample of what you're looking at together with details on what you've tried, what happened and what you don't understand about it. Include the name of the files you've looked at, what directories there in, and what distribution you're running.

 

Tom

 

0 Kudos

1,396 Views
ccd306
Contributor I

here is the cache configuration in bootloader.

 

voidcmd_gofrom_flash (int argc, char **argv){    unsigned char *src;
    ADDRESS flash_end_addr = ((ADDRESS)KERNEL_IMG_ADDRESS + (ADDRESS)KERNEL_IMG_SIZE);ADDRESS image_addr;
    /* Get/set initial/default values */    uif_dlio = UIF_DLIO_NETWORK;    image_addr = (ADDRESS)(0x40020000);
#if 1    if (!board_dlio_init())        return;
    /* Initialize network stack */    net_init();
    board_dlio_done();    cpu_cache_flush();#endif
    //memcpy((void *)&prog_info,    //       (void *)(flash_end_addr - MAX_PROGINFO_SIZE),    //       sizeof(ProgInfo));
    //if( check_program_info(TRUE) ) return;
    //src=(unsigned char *)(ADDRESS)(flash_end_addr - prog_info.prog_size -     src=(unsigned char *)(ADDRESS)(KERNEL_IMG_ADDRESS);    /* Adjust for work alignment */    if((unsigned int)src & 0x01)        (unsigned int)src--;
    /* Turn Instruction Cache ON */#if 1    mcf5xxx_wr_cacr(0        | MCF5XXX_CACR_CENB        | MCF5XXX_CACR_CINV        | MCF5XXX_CACR_DCM_IP );
    mcf5xxx_wr_acr0 (0        | FLASH_ADDRESS        | MCF5XXX_ACR_EN        | MCF5XXX_ACR_SM_IGNORE        | MCF5XXX_ACR_DCM_CB );



#endif

printf("Set CACR AND ACR0 in Evbcmds.c \n");



memcpy( (void *)image_addr,                src, KERNEL_IMG_SIZE );    //printf("start: %x, size: %x\n", prog_info.start_address, prog_info.prog_size);    //printf("src: %x\n", src);    printf("image size: %x\n", KERNEL_IMG_SIZE);    //memcpy( (void *)prog_info.start_address,    //            src, prog_info.prog_size );


    /* Disable the Instruction Cache */#if 0    mcf5xxx_wr_cacr(MCF5XXX_CACR_ICINVA); #endif

#if 1printf("Will test SDRAM SPEED HERE revise 16\n");//TestSDRAMReg();printf("Over test SDRAM SPEED HERE \n");#endif
    //cpu_pc_modify(prog_info.start_address);    cpu_pc_modify((unsigned int)(__USER_SPACE));    cpu_switch_context(FALSE);

}

0 Kudos

1,396 Views
TomE
Specialist II

That code is horribly mangled. It didn't survive your cut-and-paste. Next time use the "Insert Code" button as I am doing here:

 

/* Turn Instruction Cache ON */#if 1    mcf5xxx_wr_cacr(0 | MCF5XXX_CACR_CENB | MCF5XXX_CACR_CINV | MCF5XXX_CACR_DCM_IP );    mcf5xxx_wr_acr0 (0 | FLASH_ADDRESS | MCF5XXX_ACR_EN | MCF5XXX_ACR_SM_IGNORE | MCF5XXX_ACR_DCM_CB );#endifprintf("Set CACR AND ACR0 in Evbcmds.c \n");

 

Now you need to find the values of those constants to know what it is really doing, and to read up about them in the Reference Manual:

 

#define MCF5XXX_CACR_CENB  (0x80000000)...
#define MCF5XXX_CACR_CINV  (0x01000000)...
#define MCF5XXX_CACR_DCM_IP  (0x00000200)
#define MCF5XXX_ACR_EN            (0x00008000)
...
#define MCF5XXX_ACR_SM_IGNORE    (0x00006000)
...
#define MCF5XXX_ACR_DCM_CB        (0x00000020)

The cache is being enabled, invalidated and set "Cache Inhibited, Precise".

 

Then ACR0 is set to whatever "FLASH_ADDRESS" is, and the mask bits are left at "zero" meaning it only allows 16M starting at the FLASH address. It matches all accesses (user and supervisor) and "Cacheble Copyback".


So that code sets up the cache to be enabled on 16M of FLASH. Is that all you have or do you have more FLASH than that? This code is probably only enabling the cache to read or run the boot from the FLASH. Somewhere else it must rewrite ACR0 to map all of your FLASH, or perhaps none of it (wrting to FLASH is a bit more complicated).

 

You haven't found the code that enables the cache on the RAM though. It may be later in the boot or it may be in the Linux Kernel or more likely both.


So search for code containing "mcf5xxx_wr_acr1"

 

Tom

 

0 Kudos

1,396 Views
maxhexis
Contributor I

Hi,

 

FYI, the cache is enabled through the macro CACHE_ENABLE defined in the Linux header file include/asm-m68knommu/mcfcache.h .

There are different variations for each CPU type. If you need your specific cache mapping, you must insert an #ifdef/#endif variant fo your hardware type.

 

Bye

0 Kudos

1,396 Views
ccd306
Contributor I

  '/mnt/flash/HVBNETCPU/Apps/cpu_program'  is the Application

0 Kudos

1,396 Views
ccd306
Contributor I

This attachment is the configuration of SDRAM in kernel

0 Kudos

1,396 Views
ccd306
Contributor I

I write a test to read the value of SDRAM in driver. And I find that when I read the SDRAM Address from 0X40000000 to 0x41FFFFFF, it is fast.  when I read the SDRAM Address from 0x42000000 to 0x 43FFFFFF, it is slow. It is about 3 times slower.

Maybe it is caused by the CACR. How should I chech the CACR resigster?

 

cat /proc/maps:[SDRAM 64M]

 

40280000-40281000 rw-p 00000000 00:00 0 
43000000-433fac2d rwxp 00000000 00:00 0 
43400000-43457200 r-xs 00000000 1f:05 15         /mnt/flash/HVBNETCPU/Apps/cpu_program
4375e000-4375ffe0 rw-p 00000000 00:00 0 
43760000-43764000 rw-p 00000000 00:00 0 
43764000-43768000 rw-p 00000000 00:00 0 
4376eed0-4376eef3 rw-p 00000000 00:00 0 
4376ef10-4376ef33 rw-p 00000000 00:00 0 
4376ef50-4376ef73 rw-p 00000000 00:00 0 
4376ef90-4376efb3 rw-p 00000000 00:00 0 
437854c0-437855c0 rw-p 00000000 00:00 0 
43790000-4379ab67 rwxp 00000000 00:00 0 
43930000-4393ab7b rwxp 00000000 00:00 0 
43952130-43952153 rw-p 00000000 00:00 0 
43952170-43952193 rw-p 00000000 00:00 0 
439521b0-439521d3 rw-p 00000000 00:00 0 
439521f0-43952213 rw-p 00000000 00:00 0 
43952230-43952253 rw-p 00000000 00:00 0 
43952270-43952293 rw-p 00000000 00:00 0 
439522b0-439522d3 rw-p 00000000 00:00 0 
439522f0-43952313 rw-p 00000000 00:00 0 
43952330-43952353 rw-p 00000000 00:00 0 
43952370-43952393 rw-p 00000000 00:00 0 
439523b0-439523d3 rw-p 00000000 00:00 0 
439523f0-43952413 rw-p 00000000 00:00 0 
43952430-43952453 rw-p 00000000 00:00 0 
43952470-43952493 rw-p 00000000 00:00 0 
439524b0-439524d3 rw-p 00000000 00:00 0 
439524f0-43952513 rw-p 00000000 00:00 0 
43952530-43952553 rw-p 00000000 00:00 0 
43952570-43952593 rw-p 00000000 00:00 0 
439525b0-439525d3 rw-p 00000000 00:00 0 
439525f0-43952613 rw-p 00000000 00:00 0 
43952630-43952653 rw-p 00000000 00:00 0 
43952670-43952693 rw-p 00000000 00:00 0 
439526f0-43952713 rw-p 00000000 00:00 0 
43952770-43952793 rw-p 00000000 00:00 0 
439527b0-439527d3 rw-p 00000000 00:00 0 
439527f0-43952813 rw-p 00000000 00:00 0 
43952830-43952853 rw-p 00000000 00:00 0 
439529b0-439529d3 rw-p 00000000 00:00 0 
439529f0-43952a13 rw-p 00000000 00:00 0 
43952a70-43952ab0 rw-p 00000000 00:00 0 
4395baa0-4395baa9 rw-p 00000000 00:00 0 
4395bbc0-4395bbc2 rw-p 00000000 00:00 0 
4395bc40-4395bc42 rw-p 00000000 00:00 0 
4395bd60-4395bd63 rw-p 00000000 00:00 0 
4395be00-4395be04 rw-p 00000000 00:00 0 
4395be40-4395be4a rw-p 00000000 00:00 0 
4395bf40-4395bf43 rw-p 00000000 00:00 0 
4395bf60-4395bf6a rw-p 00000000 00:00 0 
43960000-4396ab61 rwxp 00000000 00:00 0 
43980000-43995f90 rw-p 00000000 00:00 0 
439a0000-439b5f90 rw-p 00000000 00:00 0 
43a00000-43a2d5a0 r-xs 00000000 1f:05 48         /mnt/flash/webserver/websev
43a70000-43a7f000 rw-p 00000000 00:00 0 
43b00000-43bb3229 rwxp 00000000 00:00 0 
43ea1920-43ea1943 rw-p 00000000 00:00 0 
43ea1ba0-43ea1bc3 rw-p 00000000 00:00 0 
43ea9e80-43ea9e98 rw-p 00000000 00:00 0 
43ed8000-43ed8140 rw-p 00000000 00:00 0 
43ed8400-43ed8538 rw-p 00000000 00:00 0 
43ed8600-43ed8740 rw-p 00000000 00:00 0 
43f00000-43f39a00 r-xs 00000000 1f:04 16         /bin/busybox
43f40000-43f4ab1e rwxp 00000000 00:00 0 
43f50000-43f5ab75 rwxp 00000000 00:00 0 
43f60000-43f75f90 rw-p 00000000 00:00 0 
# ---------------------------------------------------------------------------------
cat /proc/maps:[SDRAM 32M]
401ffc00-401ffc0a rw-p 00000000 00:00 0 
401ffc20-401ffc23 rw-p 00000000 00:00 0 
41000000-413fac2d rwxp 00000000 00:00 0 
41400000-414571c0 r-xs 00000000 1f:05 15         /mnt/flash/HVBNETCPU/Apps/cpu_program
41774000-41778000 rw-p 00000000 00:00 0 
41778000-4177c000 rw-p 00000000 00:00 0 
418ee6c0-418ee6c9 rw-p 00000000 00:00 0 
418eea80-418eea8a rw-p 00000000 00:00 0 
418eeac0-418eeac4 rw-p 00000000 00:00 0 
418eeea0-418eeea3 rw-p 00000000 00:00 0 
418f0000-418fab7b rwxp 00000000 00:00 0 
419126f0-41912713 rw-p 00000000 00:00 0 
41912730-41912753 rw-p 00000000 00:00 0 
41912770-41912793 rw-p 00000000 00:00 0 
419127b0-419127d3 rw-p 00000000 00:00 0 
41912830-41912853 rw-p 00000000 00:00 0 
41912870-41912893 rw-p 00000000 00:00 0 
419128b0-419128d3 rw-p 00000000 00:00 0 
419128f0-41912913 rw-p 00000000 00:00 0 
41912930-41912953 rw-p 00000000 00:00 0 
41912970-419129b0 rw-p 00000000 00:00 0 
41920000-4192ab61 rwxp 00000000 00:00 0 
41940000-41955f90 rw-p 00000000 00:00 0 
41960000-41975f90 rw-p 00000000 00:00 0 
419c0000-419ed5a0 r-xs 00000000 1f:05 48         /mnt/flash/webserver/websev
41a10000-41a1f000 rw-p 00000000 00:00 0 
41a60000-41a6ab67 rwxp 00000000 00:00 0 
41a7a000-41a7bfe0 rw-p 00000000 00:00 0 
41b00000-41bb3229 rwxp 00000000 00:00 0 
41cad400-41cad540 rw-p 00000000 00:00 0 
41e4abe0-41e4ac03 rw-p 00000000 00:00 0 
41e4ac20-41e4ac43 rw-p 00000000 00:00 0 
41e57e80-41e57e98 rw-p 00000000 00:00 0 
41e84200-41e84340 rw-p 00000000 00:00 0 
41e84400-41e84538 rw-p 00000000 00:00 0 
41ea0000-41ea1000 rw-p 00000000 00:00 0 
41ea8080-41ea8180 rw-p 00000000 00:00 0 
41eb0000-41ebab1e rwxp 00000000 00:00 0 
41ec0000-41ef9a00 r-xs 00000000 1f:04 16         /bin/busybox
41f00000-41f0ab75 rwxp 00000000 00:00 0 
41f20000-41f35f90 rw-p 00000000 00:00 0 
# -------------------------------------------------------------------------------------------------------

 

0 Kudos

1,396 Views
ccd306
Contributor I

here are the information of ps aux, cat cpuinfo, cat zoneinfo(SDRAM SIZE IS 64M)

 

 

# ------------------------------------------------------------------
# ps aux
  PID  Uid     VmSize Stat Command
    1 0               SW  init      
    2 0               RWN [ksoftirqd/0]
    3 0               RW< [events/0]
    4 0               SW< [khelper]
    5 0               SW< [kthread]
    8 0               SW< [kblockd/0]
   11 0               SW< [khubd]
   32 0               SW  [pdflush]
   33 0               SW  [pdflush]
   34 0               SW  [kswapd0]
   35 0               SW< [aio/0]
  571 0               SW  [mtdblockd]
  603 0               SWN [jffs2_gcd_mtd4]
  621 0               SWN [jffs2_gcd_mtd5]
  623 0               SW  /bin/sh /bin/runapp 
  624 0               SW  /bin/sh /bin/runwebsev 
  626 0               SW  /bin/sh 
  629 0               SW  /mnt/flash/webserver/websev 
  673 0               SW< [ds1337]
  678 0               SW  /mnt/flash/HVBNETCPU/Apps/cpu_program 
  679 0               SW  /mnt/flash/HVBNETCPU/Apps/cpu_program 
  680 0               RW  /mnt/flash/HVBNETCPU/Apps/cpu_program 
  681 0               SW  /mnt/flash/HVBNETCPU/Apps/cpu_program 
  687 0               RW  ps aux 
# ------------------------------------------------------------------
# cat cpuinfo 
CPU:            COLDFIRE(m537x)
MMU:            none
FPU:            none
Clocking:       179.4MHz
BogoMips:       119.60
Calibration:    59801600 loops
# ------------------------------------------------------------------
# cat zoneinfo 
Node 0, zone   Normal
  pages free     11400
        min      256
        low      320
        high     384
        active   1036
        inactive 1044
        scanned  0 (a: 0 i: 0)
        spanned  16384
        present  16384
        protection: (0, 0, 0, 0)
  pagesets
    cpu: 0 pcp: 0
              count: 5
              high:  18
              batch: 3
    cpu: 0 pcp: 1
              count: 0
              high:  6
              batch: 1
  all_unreclaimable: 0
  prev_priority:     12
  temp_priority:     12
  start_pfn:         262144
# ------------------------------------------------------------------

 

0 Kudos

1,396 Views
TomE
Specialist II

"Top" doesn't show any one job hogging the CPU.

 

If you run something CPU bound it'll show up with a high "CPU%" figure.

 

You're not getting that.

 

You'll have to learn how to interpret this information. The next thing to do would be to save as much information as you can (top, ps, all the other things) and then *COMPARE* a 32M and a 64M system, looking for differences.

 

You haven't answered my original question, which was "what does your application DO?" It certainly isn't showing up in that list as hogging the CPU. Then you'll have to instrument and debug your Application to find out what it is doing and why it is behaving differently.

 

Another idea.

 

It is possible that your memory configuration is wrong somehow. Maybe the cache control code, specifically the code that writes to the CACR, ACR0 and ACR1 registers. Search ALL your code for matches on "ACR0" and "ACR1". Note that this code might be in whatever is used to boot the CPU, and not in the Linux source.

 

If the cache is set up to default to "uncached" and ACR0 and ACR1 are set up to enable cache on RAM, then maybe they're only set up to cache 32M, so half of your 64M is running uncached. That would make it slow. This may have been "hardcoded in hex" by someone, or there may be a configuration variable somewhere that says how much RAM there is - other than whatever you changed to enable the RAM controller to access 64M.

 

You could also write a test program that allocates large blocks of RAM and then times some memory copy operations. You may find some addresses are slower than others if the cache is set up wrong.

 

Tom

 

0 Kudos

1,396 Views
ccd306
Contributor I

or you can see the attachment picture which is the top command information.(SDRAM SIZE IS 64M) 

I think it is ok.

0 Kudos

1,396 Views
ccd306
Contributor I

This is the information when using TOP command (SDRAM SIZE IS 64M)

 

 

Mem: 17684K used, 45588K free, 0K shrd, 4096K buff, 4224K cached
Load average: 2.07, 1.73, 0.95    (State: S=sleeping R=running, W=waiting)
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
   33 0        SW         0     5  0.0  0.0 
   32 0        SW         0     5  0.0  0.0 
  623 0        SW         0     1  0.0  0.0 
    2 0        RWN        0     1  0.0  0.0 
  629 0        SW         0   624  0.0  0.0 
   34 0        SW         0     1  0.0  0.0 
    4 0        SW<        0     1  0.0  0.0 
    3 0        SW<        0     1  0.0  0.0 
  571 0        SW         0     1  0.0  0.0 
  624 0        SW         0     1  0.0  0.0 
  679 0        SW         0   678  0.0  0.0 
  680 0        RW         0   679  0.0  0.0 
  678 0        SW         0   623  0.0  0.0 
  681 0        SW         0   679  0.0  0.0 
    5 0        SW<        0     1  0.0  0.0 
   11 0        SW<        0     5  0.0  0.0 
    8 0        SW<        0     5  0.0  0.0 
  621 0        SWN        0     1  0.0  0.0 d5
  603 0        SWN        0     1  0.0  0.0 d4
  673 0        SW<        0     5  0.0  0.0 

 

0 Kudos

1,396 Views
ccd306
Contributor I

If you need more information, you can reply here or email to me. My office mail is  chuandong.cheng@honeywell.com. Thanks.

0 Kudos

1,396 Views
TomE
Specialist II

How much slower?

 

There are no timestamps on the startup logs you included, so there's no information there on where the extra time is being taken.

 

If you watch the startup, which lines of printout are taking longer to come out?

 

There's an extra 32M or RAM to initialise. It may be zeroing or testing it somewhere.

 

Tom

 

0 Kudos

1,396 Views
ccd306
Contributor I

it is about 10 times slower.

Sorry, Maybe I didnot discribed the question detailly. 

 

I test it in application process. 

Our platform includes MCF5372L  and FPGA. So the firmware is composed of Bootloader,FPGA,Kernel , Application and FileSystem.  

when I test, the bootloader,FPGA, Filesystem and application are the same.

And then I configure the SDRAM SIZE AS 64M/32M Bytes in Kernel to build the kernel.

 

there is a LED flash in Application to test the speed.

I just upgrade the Kernel. 

If the Kernel is configured as 64M. It is much more slow. it is about 10times slower.

 

0 Kudos

1,396 Views
TomE
Specialist II

By providing the Boot Startup results, it implied it was taking longer to boot.

 

> there is a LED flash in Application to test the speed.

 

Speed of it doing what? What does your "Application" actually do? Is it I/O bound, memory bound, is it reading and writing files or what?

 

Is the Application running 100% in a polling loop? That's not a good way to run things under Linux if that is what it is doing.

 

You have a console. Run the command "top" and see what it says the system is doing. If you don't have "top" built into busybox, then try and add it. Try "ps aux" and other variants to try and see where the CPU's time is being taken up.

 

Look in the "/proc/sys" filesystem. Type "man proc" into a desktop Linux box to learn about what is in there. If you haven't built a kernel wit  /proc support, then add it (if uClinux allows this).

 

You're running "uClinux" and not a "real one", so there may be some restrictions in the commands yu have available that I don't know about. We're running a "real" Linux on an MPC5200 which has an MMU, and that's the reference I'm using to try and help you.

 

Tom

 

0 Kudos

1,396 Views
ccd306
Contributor I

Thanks for your reply. I will add the top and check it. 

Because I will have a day leaving tomorrow. So I will give you results this Friday. Thanks.

0 Kudos