On Thursday 28 August 2014 14:37:54 Rafał Miłecki wrote:

On 28 August 2014 13:56, Arnd Bergmann [off-list ref] wrote:

quoted

On Thursday 28 August 2014 13:39:55 Rafał Miłecki wrote:

quoted

switch (boot_device) {
case BCMA_BOOT_DEV_NAND:
    nvram_address = 0x1000dead;
    break;
case BCMA_BOOT_DEV_SERIAL:
    nvram_address = 0x1000c0de;
    break;
}

I don't understand. Why does the nvram address depend on the boot
device?

NVRAM is basically just a partition on flash, however there are few
tricks applying to it.

Ah, that explains a lot! I was thinking of hardware nvram, which I assume
it was on some early hardware.

To make booting possible, flash content is mapped to the memory. We're
talking about read only access. This mapping allows CPU to get code
(bootloader) and execute it as well as it allows CFE to get NVRAM
content easily. You don't need flash driver (with erasing & writing
support) to read NVRAM.

Ok. Just out of curiosity, how does the system manage to map NAND
flash into physical address space? Is this a feature of the SoC
of the flash chip?

I guess for writing you'd still use the full MTD driver, right?

Depending on the boot flash device, content of flash is mapped at
different offsets:
1) MIPS serial flash: SI_FLASH2 (0x1c000000)
2) MIPS NAND flash: SI_FLASH1 (0x1fc00000)
3) ARM serial flash: SI_NS_NORFLASH (0x1e000000)
4) ARM NAND flash: SI_NS_NANDFLASH (0x1c000000)

So on my ARM device with serial flash (connected over SPI) I was able
to get NVRAM header this way:

void __iomem *iobase = ioremap_nocache(0x1e000000, 0x1000000);
u8 *buf;

buf = (u8 *)(iobase + 0xff0000);
pr_info("[NVRAM] %02X %02X %02X %02X\n", buf[0], buf[1], buf[2], buf[3]);

This resulted in:
[NVRAM] 46 4C 53 48

(I hardcoded 0xff0000 above, normally you would need to try 0x10000,
0x20000, 0x30000 and so on...).

Does that mean the entire 0x1e000000-0x1f000000 area is mapped to
the flash and you are looking for the nvram in it, or that you don't
know where it is?

	Arnd