(sorry I can't post a proper reply message, I picked that up from the archives)
Nathan Williams <nathan at traverse.com.au> wrote:
I am suspicious that the reset problem only occurs when I'm using a laptop hard drive off the 44pin IDE connector on our board. I have tried booting with a 3.5" drive and external 12V, but I can't replicate the problem. With the 3.5" drive, a reboot from fsck works fine. Hopefully the next PCB revision should perform better because we've moved the 5V plane further away from the DDR tracks.
I don't know if I mentioned another problem that has similar symptoms. Some RAM causes the same cache disable problem, even if there are no IDE devices connected. This happens from power-up, so it's not a reset issue.
I'm facing a very similar issue here on an ALIX.2D board which is based on the same chipset. The problem happens to occur only sometimes, just like you described it, and resetting from Linux gives a higher change of provoking it. However, I also have once out of 20 power-up cycles as well.
What's really strange about that is the fact that sometimes, not even power cycling will fix it - coreboot will always ever stop at the same point (from what I've traced, exactly at the same instructions that you pointed out). Powering off and waiting for ~10 minutes likely brings the board back to life.
Connecting or disconnecting extern IDE44 drives does not appear to affect the probability, though. One more thing that bring some awareness is that the effect is harder to trigger when booting from an external LPC flash emulator (in contrast to coreboot flashed to the internal LPC).
I urgently need to resolve that and would appreciate any more hints about where to add more code for flushing caches and the like. I also suspect the reset vector to not properly flush the hardware, but I'm somewhat lost in this codebase I must admit, and Geode is also nothing I'm terribly familiar with.
Thanks, Daniel