Current Hacks

Recent site activity

Testing ram after an upgrade

This is a simple way to test the ram after you've done an upgrade, you will need access to the uboot console.
 
Once you've done the upgrade, edited uboot properly and flashed it to the frame, you're going to want to test that the ram really is working, it's been suggested that the ram will wrap around if it's misconfigured, so we simply run some memory write and read tests at specific memory addresses to see whether we've got 64,32,16 or 8MB,  at the uboot console, copy and paste the following 2 lines into it one at a time:
 
setenv chkmem 'echo 'writing to memory'; mw 0x34000000 dead64ef; mw 0x33000000 dead48ef; mw 0x32000000 dead32ef; mw 0x31000000 dead16ef; mw 0x30800000 dead8eef;  run readmem '
 
setenv readmem 'echo 'reading memory'; md 0x33000000 4; md 0x32000000 4; md 0x31000000 4; md 0x30800000 4; md 0x30000000 4'
 
you can run the command by entering the following at the uboot console:
run chkmem
 
Depending on how big the ram was you should see something similar to the following:
 
writing to memory
reading memory
33000000: dead48ef 00243d5b 00060a15 00000a13    .H..[=$.........
32000000: dead32ef 918daad2 756584b1 9932c12a    .2........eu*.2.
31000000: dead16ef 75005b78 ab2a18b2 2645c165    ....x[.u..*.e.E&
30800000: dead8eef 2c0bc6ef 80efa09f f258a795    .......,......X.
30000000: dead64ef 2bce092b 21944159 fe0c4cc2    .d..+..+YA.!.L..
 
 
so what does it all mean?  With the first 2 lines you pasted into the uboot console, you setup a uboot 'env variable', env variables allow you to setup strings of commands or environment variables that uboot uses to perform various functions.
 
The first of the env variables we setup is called chkmem, it writes the hex bytes 'deadbeef' to 64, 48, 32, 16 and 8MB in ram, substituting 'be' for the size of the ram chip we are testing (8,16,32,64MB).  Once it's written to the ram it calls the second env variable we setup, readmem.
 
readmem reads back the memory addresses that we've just written and displays it to us.
 
they're read back in order that they're written, if you look at the 2nd column you can easily see how much ram your uboot is seeing.  Mine is seeing 64MB, yours will be seeing the biggest value that you see in the list,.so if you see 30000000: dead64ef 2bce092b 21944159 fe0c4cc2 .d..+..+YA.!.L..
 
You've got 64MB showing!!
 
 
The ram does indeed wrap around, I tested this by writing to 0x35000000 and reading it, which would be 80MB, which doesn't exist on my photoframe, this is the result:
 
  mw 0x35000000 deadbeef
  md 0x35000000
  35000000: deadbeef 75005b78 ab2a18b2 2645c165    ....x[.u..*.e.E&
Hmmmn, this looks familiar, it looks very much like 31000000, lets test that theory:
  md 0x31000000
  31000000: deadbeef 75005b78 ab2a18b2 2645c165    ....x[.u..*.e.E&
Sure enough, we can see that 80MB and 16MB are the same place, so we definitely only have 64MB of ram on this board and it wrapped around.  80-64= 16MB, that's why it ended up at 0x31000000, 16MB in the memory address.
 
These env vars are a catch all solution, the highest value you see in place of be in deadbeef for each of the memory addresses we're writing to is how much ram there is, at least that's the theory, it's all multiples of 8,16,32MB.
 
If you look at the last value that is read back to you, 0x30000000, that should contain the value of your ram.  I know it probably seems slightly counter intuitive that memory address zero shows dead64ef in the above example but it's entirely because of wrap around and writing the memory addresses from high to low that causes this to work, whatever value is in 0x30000000 is the amount of ram in the system, if you only had 8MB of ram in the system, then all of the addresses would show dead8eef in column 2 :)  I probably didn't need to put 48MB in the memory test but hey, that's another 4bytes that you know works, right?  Only if you've got 64MB of ram on the df3210 :D
Comments