Skip to main content.

14.2.4. U-Boot crashes after relocation to RAM

Question:
I have ported U-Boot to a custom board. It starts OK, but crashes or hangs after relocating itself to RAM. Why?

Answer:
Your SDRAM initialization is bad, and the system crashes when it tries to fetch instructions from RAM. Note that simple read and write accesses may still work, it's the burst mode that is failing. This only shows up when caches are enabled because cache is the primary (or only) user of burst operations in U-Boot. In Linux, burst accesses may also result from DMA. For example, it is typical that a system may crash under heavy network load if the Ethernet controller uses DMA to memory.

ALERT! It is NOT sufficient to program the memory controller of your CPU; each SDRAM chip also requires a specific initialization sequence which you must adhere to to the letter - check with the chip manufacturer's manual.

It has been observed that some operating systems like pSOS+ or VxWorks do not stress the memory subsystem as much as Linux or other UNIX systems like LynxOS do, so just because your board appears to work running another OS does not mean it is 100% OK.

Standard memory tests are not effective in identifying this type of problem because they do not cause stressful cache burst read/write operations.

With this caveat in mind, reportedly this program has found memory problems before: http://pyropus.ca/software/memtester/

Argument:
But my board ran fine with bootloader XYZ and/or operating system ABC.

Answer:
Double-check your configuration that you claim runs properly...

  1. Are you sure the SDRAM is initialized using the same init sequence and values?
  2. Are you sure the memory controlling registers are set the same?
  3. Are you sure your other configuration uses caches and/or DMA? If it doesn't, it isn't a valid comparison.
14.2.3. Source object has EABI version 4, but target has EABI version 0 1. Abstract 14.2.5. Warning - bad CRC, using default environment
Prev Home Next