Re: Booting bcm47xx (bcma & stuff), sharing code with bcm53xx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 28 August 2014 14:37:54 Rafał Miłecki wrote:
> On 28 August 2014 13:56, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Thursday 28 August 2014 13:39:55 Rafał Miłecki wrote:
> >> 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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux