Kernel fails to boot with "crc error -- System halted"

[AJEllisuk]

Hi

I have run into a major problem in that when I program my kernel into flash on my system or try and run it from RAM I get the following output:

## Booting image at 00060000 ...
## Copy image from flash 00060000 to ram 00200000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1871640 Bytes = 1.8 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................. .................................................. ....................

crc error

-- System halted


The checksum passes, but the image type is uncompressed, so why is the kernel trying to decompress?

From a successful build I had the same message about uncompressing the kernel, so I don't understand what the problem is. I have previously been able to build and run kernels without the above problem. I cannot work out what I have done to cause this problem, could someone please enlighten me as to what could be going wrong?

Kind regards

Andrew

[Rubberman]

It may be a memory problem. If you don't have ecc or parity-checked RAM, then a bad RAM chip can cause this sort of problem. This is my answer because right now I don't have any better ideas!

[AJEllisuk]

It may be a memory problem. If you don't have ecc or parity-checked RAM, then a bad RAM chip can cause this sort of problem. This is my answer because right now I don't have any better ideas!

Hi Rubberman,

Thank you for your reply.

I have carried out some tests to determine whether there is a problem with the RAM:

1. I have used the memtest function in u boot
2. I entered the processors iboot mode and wrote 0xAA55 to the RAM normally occupied by the kernel and then 0x55AA and verified the ram to be ok
3. I tried on old binary I have which is just short of 1MB and it executed without any problems.
4. I tried loading the kernel to 0x200000, insted of 0x8000 and had the same problem.
5. I tried all the above on 2 other boards

I am fairly sure there is something wrong with my build process. But I cannot find what it is.

Do you have any further suggestions please?

[Rubberman]

I'll have to think about it some more. Right now I have to restore.y system. This is from my phone...

[AJEllisuk]

Hi Rubberman,

The issue seems to be random in it's occurrence, and a full power cycle always cures it.

After chatting with a friend about this issue, I have a theory that the problem I have may be caused by the DDR memory controller in my processor not being set up correctly. Unfortunately I cannot find any information about how to do this with my processor (MCS8144). The evaluation board I have uses different DDR memory and the set up stored in the config had some factors for the DDR, but I have no way of knowing what the settings do.

Andrew

[Rubberman]

All dram have different specs, mostly with regard to timing issues, number of clocks to refresh their memory cells, etc. The system memory bus timing and CPU interactions with it have to be tuned accordingly. My guess is that the config specs related to DDR RAM has to do with tuning the system for these differences. With full specs on the board, RAM, and CPU I can't say much more than that. My advice would be to contact the board manufacturer for guidance.

[AJEllisuk]

Hi Rubberman

Thank you for your reply. I have been in contact with Moschip who supply the processor used on my board several times and they just don't answer, I have had read receipts so I know they have opened and read my email.

From the documentation I can see that to configure the DDR controller I need to supply the following information

• The number of registers to configure
• The address of the first register to configure
• The data value to be written to the first register
• The address of the second register to configure
• The data value to write to the second register
• And so on...

However I cannot find anywhere, even in the DDR's data sheet (MT47H128M16), what to put in these registers. Do you have any suggestions?

Andrew

[Rubberman]

Other than to get the spec and programming sheets for the DDR controller, I am clueless at this point. Looking at what the kernel does on startup may help also. I've never had to dig in this far. The last time I had to diddle with hardware at this level was in the late 1970's when I was building an 8048-based rally computer on a wire wrapped breadboard...