linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Hauke Mehrtens <hauke@hauke-m.de>
Subject: Re: Booting bcm47xx (bcma & stuff), sharing code with bcm53xx
Date: Thu, 28 Aug 2014 17:32:38 +0200	[thread overview]
Message-ID: <6633831.1CSHMPPLH1@wuerfel> (raw)
In-Reply-To: <CACna6rx0E_s76wLLkDjj90sXH=Q3yzBemQM5Qrp96QiWCWr0qg@mail.gmail.com>

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

  reply	other threads:[~2014-08-28 15:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-26 16:42 Booting bcm47xx (bcma & stuff), sharing code with bcm53xx Rafał Miłecki
2014-08-26 20:32 ` Hauke Mehrtens
2014-08-26 21:14   ` Arend van Spriel
2014-08-27  6:07   ` Rafał Miłecki
2014-08-28 10:13 ` Arnd Bergmann
2014-08-28 10:47   ` Rafał Miłecki
2014-08-28 11:02     ` Arnd Bergmann
2014-08-28 11:39       ` Rafał Miłecki
2014-08-28 11:56         ` Arnd Bergmann
2014-08-28 12:37           ` Rafał Miłecki
2014-08-28 15:32             ` Arnd Bergmann [this message]
2014-08-28 16:00               ` Rafał Miłecki
2014-08-28 16:03                 ` Rafał Miłecki
2014-08-28 21:22           ` Hauke Mehrtens
2014-08-29  7:12             ` Arnd Bergmann
2014-08-29 15:21             ` Rafał Miłecki
2014-08-29 20:04               ` Arnd Bergmann
2014-08-30 13:33                 ` Hauke Mehrtens
2014-08-31  9:20                 ` Rafał Miłecki
2014-09-01  7:48                   ` Rafał Miłecki
2014-09-01 14:57                     ` Arnd Bergmann
2014-09-01 20:45                       ` Jonas Gorski
2014-09-01 20:57                         ` Arnd Bergmann
2014-08-31 19:49                 ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6633831.1CSHMPPLH1@wuerfel \
    --to=arnd@arndb.de \
    --cc=hauke@hauke-m.de \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=zajec5@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).