On 28 August 2014 13:56, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday 28 August 2014 13:39:55 Rafał Miłecki wrote: >> On 28 August 2014 13:02, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> > On Thursday 28 August 2014 12:47:29 Rafał Miłecki wrote: >> >> On 28 August 2014 12:13, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> > My impression is that all the information that you need in these early >> >> > three steps is stuff that is already meant to be part of DT. >> >> > This isn't surprising, because the bcm47xx serves a similar purpose >> >> > to DT, it's just more specialized. >> >> > >> >> > This duplication is a bit unfortunate, but it seems that just using >> >> > the respective information from DT would be easier here. >> >> > >> >> > Is any of the information you need early dynamic? It sounds that >> >> > for a given SoC, it should never change and can just be statically >> >> > encoded in DT. >> >> >> >> I'm not sure which info you exactly are talking about. I believe one >> >> SoC model always use the same CPU, ChipCommon, embedded wireless and >> >> PCIe + USB controllers. However amount of RAM, type of flash (serial >> >> vs. NAND), size of flash, booting method, NVRAM location, etc. all >> >> depend on vendor's choice. I think CPU speed could also depend on >> >> vendor choice. >> > >> > But those would also be present in DT on ARM, right? >> >> Well, that depends. Hauke was planning to put info about flash in DT. >> Me on the other hand suggested reading info about flash from the >> board. See my reply: >> https://www.mail-archive.com/devicetree@xxxxxxxxxxxxxxx/msg39365.html >> >> My plan was to use patch like >> [PATCH] bcma: get & store info about flash type SoC booted from >> http://www.spinics.net/lists/linux-wireless/msg126163.html >> (it would work on both: MIPS and ARM) >> and then: >> >> 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. 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. 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...). -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
