[PATCH] powerpc: Create "rom" (MTD) device prpmc2800
David Gibson
david at gibson.dropbear.id.au
Wed Jun 6 12:39:39 EST 2007
On Mon, Jun 04, 2007 at 01:56:46PM -0700, Mark A. Greer wrote:
> Okay, >25 msgs from a ~10 line patch. I think that's a new personal
> record for me. ;)
>
> More seriously, I've simply been trying to provide a DT node that works
> with the current code in drivers/mtd/maps/physmap_of.c. Obviously,
> there are issues with that code and my DT node.
>
> So to try a different approach, here is the hardware info and a copy of
> the relevant DT that I currently have. Segher, et. al., if you can
> find the time, please give me your best guidance as to what the DT
> node(s) should really look like (and how physmap.c should really work).
> I'll be happy to hack physmap_of.c once I have a clear understanding of
> how it should work (and there is clear agreement on that :).
>
> Mark
> ---
>
> Hardware:
> ---------
> [As I read this, I realize I have the DT node messed up anyway.]
> - Not that this matters but this is a Marvell mv64360/mv64362 based board
> with a MPC7447A processor.
> - There are two 32MB banks of two Intel Stata Flash (NOR) chips (CFI).
> Each 32MB bank is 32-bits wide built with two 8Mx16 28F128K3 devices
> (http://download.intel.com/design/flcomp/datashts/29073709.pdf).
> Bits 0-15 from the first device, bits 16-31 from the second one.
> The two banks are contiguous in the processor's physical memory space.
> - The MTD partitions are described in the DT.
>
> For your reference, the exiting DT:
> -----------------------------------
>
> mv64x60 at f1000000 { /* Marvell Discovery */
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <1>;
> model = "mv64360"; /* Default */
> compatible = "marvell,mv64x60";
> clock-frequency = <7f28155>; /* 133.333333 MHz */
> reg = <f1000000 00010000>;
> virtual-reg = <f1000000>;
> ranges = <88000000 88000000 01000000 /* PCI 0 I/O Space */
> 80000000 80000000 08000000 /* PCI 0 MEM Space */
> a0000000 a0000000 04000000 /* User FLASH */
> 00000000 f1000000 00010000 /* Bridge's regs */
> f2000000 f2000000 00040000>; /* Integrated SRAM */
>
> flash at a0000000 {
> device_type = "rom";
> compatible = "direct-mapped";
> reg = <a0000000 4000000>; /* Default (64MB) */
> probe-type = "CFI";
> bank-width = <4>;
> partitions = <00000000 00100000 /* RO */
> 00100000 00040001 /* RW */
> 00140000 00400000 /* RO */
> 00540000 039c0000 /* RO */
> 03f00000 00100000>; /* RO */
> partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
> };
Whatever Segher says, I think it's fine to have the partition
information here. It may not be hardware information, but it is
(often) firmware information; there are plenty precedents for things
like this in the device tree and it doesn't get in the way of any real
hardware information.
That said, I'm a bit dubious about the encoding of the RO/RW bit into
the partition length (which I only just realised was used now).
I'll have to think some more about the rest.
> So, what should the DT look like for this thing? And, what should
> phymap_of.c be doing?
>
> Mark
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
More information about the Linuxppc-dev
mailing list