Hi, >>> + PRINTK_DEBUG(" Reading RAM at 0x%08x => 0x%08x\n", (dimm_start * >>> 32 * 1024 * 1024), read32(dimm_start * 32 * 1024 * 1024)); >>> >>> >> There is a good chance that this read does not happen unless debugging >> is enabled. Is that on purpose? >> It would be clearer to pull this out of the PRINTK like this: >> >> #if CONFIG_RAM_DEBUG >> u32 value = read32(dimm_start * 32 * 1024 * 1024); >> PRINTK_DEBUG(" Reading RAM at 0x%08x => 0x%08x\n", (dimm_start * 32 >> * 1024 * 1024), value); >> #endif >> > > Yes that is on purpose. I guess I could use a preprocessing directive, > but I thought that was the point of the macro. well yes and no. There is no guarantee that the read is executed even if CONFIG_RAM_DEBUG is on. So it is not side effect free.
> Performing dummy read/write > Reading RAM at 0x20000000 => 0xf5ba55aa > Writing RAM at 0x20000000 <= 0x55aa55aa > Reading RAM at 0x20000000 => 0x55aa55aa So this read/write is only for debugging? It will break suspend/resume, should you intend to go for that. Stefan -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot