All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rogério Brito" <rbrito@ime.usp.br>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Old regression with MTD devices disappearing from a Kurobox HD/HG
Date: Thu, 9 Apr 2015 20:12:50 -0300	[thread overview]
Message-ID: <20150409231250.GA23450@ime.usp.br> (raw)
In-Reply-To: <1428618510.22867.548.camel@freescale.com>

Hi, Scott.

On Apr 09 2015, Scott Wood wrote:
> On Thu, 2015-04-09 at 18:54 -0300, Rogério Brito wrote:
> > Dear Scott and other people,
> > 
> > Just for the record, I am passing now the following command line option to
> > the kernel:
> > 
> >     mtdparts=myflash:4096k(allflash),3072k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf)
> 
> What is "myflash"?  You need to match the device name that the kernel
> uses.

>From the documentation that I read, it *seemed* to be an arbitrary name and,
to be screamingly different from anything else, I just picked "myflash".
So, in my case (see dmesg snippet below), I would use "physmap-flash.0",
right? Or would that be "physmap-flash"? Or something else entirely?

,----
| (...)
| ata1: PATA max UDMA/133 cmd 0xbffed0 ctl 0xbffed8 bmdma 0xbffef0 irq 17
| ata2: PATA max UDMA/133 cmd 0xbffee0 ctl 0xbffee8 bmdma 0xbffef8 irq 17
| physmap platform flash device: 00400000 at ffc00000
| physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000004 Chip ID 0x00007e
| Amd/Fujitsu Extended Query Table at 0x0040
|   Amd/Fujitsu Extended Query version 1.3.
| physmap-flash.0: Swapping erase regions for top-boot CFI table.
| number of CFI chips: 1
| r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
| (...)
`----

> What is "allflash"?  If the flash is only 4 MiB and you're trying to
> make the first partition refer to the entire flash, it won't work.
> It'll see that 4 MiB partition and ignore the rest as being beyond the
> end of the device.

OK, I was just trying to mimic the layout that you can see here:

    http://buffalo.nas-central.org/wiki/Flash_ROM#Checking_the_layout_.28with_kernel_2.6.x.29

> > Do the options CONFIG_MTD_CMDLINE_PARTS and CONFIG_MTD_OF_PARTS somehow
> > "conflict" with each other?
> 
> No.  CONFIG_MTD_OF_PARTS only matters if you're describing the flash
> chip in the device tree, and even then cmdline mtdparts takes precedence
> if present.

Great to know. I hope that one way or another we can have these partitions
specified in the device tree so that:

* The device tree sources better reflect the reality and describe the
  hardware closer than they do today.
* I can clean up my command line.


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

  reply	other threads:[~2015-04-09 23:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-04  5:40 Old regression with MTD devices disappearing from a Kurobox HD/HG Rogério Brito
2015-04-07 22:34 ` Scott Wood
2015-04-07 23:58   ` Rogério Brito
2015-04-08  0:02     ` Scott Wood
2015-04-08  0:37       ` Rogério Brito
2015-04-08  0:50         ` Scott Wood
2015-04-08  1:13           ` Rogério Brito
2015-04-08  1:27             ` ) Scott Wood
2015-04-08  1:56               ` Old regression with MTD devices disappearing from a Kurobox HD/HG Rogério Brito
2015-04-09 21:54                 ` Rogério Brito
2015-04-09 22:28                   ` Scott Wood
2015-04-09 23:12                     ` Rogério Brito [this message]
2015-04-16 22:55                       ` Rogério Brito
2015-04-16 23:27                         ` Scott Wood
2015-04-17  0:01                           ` Rogério Brito
2015-04-17  0:03                             ` Scott Wood
2015-04-17  0:14                               ` Rogério Brito

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=20150409231250.GA23450@ime.usp.br \
    --to=rbrito@ime.usp.br \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=scottwood@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.