Hello.
I'm having sort of vacation, mostly away from computer, hence my belated
reply...
David Gibson wrote:
>>>>>Can you describe some of the options for *not* direct mapped flash
>>>>>chips - I can't reasonably come up with a way of describing the
>>>>>distinction when I've never seen NOR flash other than direct mapped.
>>>> You're lucky to live in the single-endian world. Once you're in
>>>> bi-endian
>>>>one, all kinds of strange mappings become possible. I've seen the MIPS
>> Well, not necessarily -- 16-bit only accesses are always possibly (no
>>dount this would be a strange mapping however)...
> I have no idea what you're getting at here.
The code fragment that I've posted before -- it used readw() in read8()
method of the mapping.
>>>>mapping driver which required swapping flash bytes in s/w in BE mode, i.e.
>>>>couldn't be served by physmap, yet that's not all... here's the code of
>>>>its
>>>>map read*() methods:
>>>Aha! Ok, now I understand the sorts of situations you're talking
>>>about. By "not direct mapped", I thought you were talking about some
>>>kind of access via address/data registers on some indirect bus
>>>controller, rather than weird variations on endianness and
>>>bit-swizzling.
>> No, that would be just too ridiculous for a NOR flash -- I hope. :-)
> Heh. In my experience, very little is so ridiculous that some
> embedded vendor won't do it.
Right. :-)
>>>Hrm.. this is a property of how the flash is wired onto the bus,
>>>rather than of the flash chips themselves,
>> Indeed.
>>>so I'm not entirely sure where description of it belongs.
>> So, you're saying that the 1:1 address correspondence rule stops to apply
>>here?
> Well.. it all depends what exactly you consider the address space of
> the flash bank. By which I mean the whole shmozzle represented by the
> device node, not the individual flash chips. It's not immediately
> obvious whether or not that should include any swizzling done by the
> bus wiring.
> It would be possible, I guess, to define a 'swizzled-ranges' property
> or something which allows child devices to be embedded in the parent's
> address range in a not-direct way. However, the swizzling on the
> flash bank is really a property of the flash bank, not of the parent
> bus - requiring it to be encoded in the parent is pretty yucky -
> especially if the flash bank is just part of a larger chunk of bus
> address space, defined by a single large ranges entry in the parent.
[...]
>>>>>>>+ - reg : Address range of the flash chip
>>>>>>>+ - bank-width : Width (in bytes) of the flash bank. Equal to the
>>>>>>>device width
>>>>>>>+ times the number of interleaved chips.
>>>>>>>+ - device-width : (optional) Width of a single flash chip. If
>>>>>>>omitted,
>>>>>>>+ assumed to be equal to 'bank-width'.
>>>>>> Why then not just introduce the "interleave" prop and obsolete the
>>>>>>"bank-width"?
>>>>>Because they're equivalent information, and bank-width is what the
>>>>>code ends up actually caring about. I don't see any reason to prefer
>>>>>giving the interleave.
>>>> Well, "device-width" is not the thing that we care about either. ;-)
>>>Well, yes but we need to encode it somehow. Segher preferred
>>>device-width to interleave, because it's closer to a description of
>>>the actual hardware, rather than an abstration decribing its wiring.
>>>In other words I *still* don't see any reason to prefer giving the
>>>interleave.
Well, for example, enable "Flash chip driver advanced configuration
options" (appers in the "RAM/ROM/Flash chip drivers menu" when you enable CFI
probe, and it has a choice of bus widths 8 to 256 bits (here buswidth == bank
width) and *interleave factors* 1 to 8...
>> I wasn't talking of "interleave" preference over "device-width", I was
>>talking about obsoleting "bank-width" with this pair.
> Whatever. You haven't given any argument to prefer interleave over
> either device-width or bank-width.
Consistency? The bank width is a product of the chip width and interleave
factor. However, I don't insist. The MTD core itself has a different view on
the CFI flash geometry: bank width (which is a property of a mapping driver)
and interleave (which is a property of a chip driver).
>>>>>>>Index: working-2.6/drivers/mtd/maps/physmap_of.c
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30
>>>>>>>17:07:11.000000000 +1000
>>>>>>>+++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30
>>>>>>>17:07:14.000000000 +1000
>>>>[...]
>>>>>>>@@ -221,6 +297,14 @@ err_out:
>>>>>>>
>>>>>>>static struct of_device_id of_physmap_match[] = {
>>>>>>> {
>>>>>>>+ .compatible = "cfi-flash",
>>>>>>>+ .data = (void *)"cfi_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>>>+ .compatible = "jedec-flash",
>>>>>>>+ .data = (void *)"jedec_probe",
>>>>>>>+ },
>>>>>>>+ {
>>>>>> This would also trigger on non-linearly mapped CFI or JEDEC
>>>>>>flashes which is not a good idea -- however, as we're using the MTD
>>>>>>probing code anyway, it will just fail, so it's not luckily is not a
>>>>>>fatal design flaw.
>>>>>Well, if there's nothing else to distinguish them. Which there isn't
>>>>>yet, but will need to be: see above about incomplete - helpful
>>>>>suggestions about how to describe the mapping would be more useful
>>>>>than merely pointing out the lack.
>>>> I was thinking about adding "direct-mapped" prop... but maybe adding
>>>>"ranges" to the parent node (that's "ebc") would indeed ensure that the
>>>>flash
>>>>is mapped 1:1 to the EBC's parent bus also.
>>>The ebc already has a ranges property. But that can't describe the
>> Not in the device tree that started that thread -- I haven't seen another.
> Ah sorry. The ranges property isn't in the dts, it's added by the
> bootwrapper based on the EBC register contents.
Cool. :-)
>>>sorts of bit-swizzling you're talking about.
>> Let's hear what Segher says (if he's not yet tired of all this :-).
>>>>>>>Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
>>>>>>>===================================================================
>>>>>>>--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30
>>>>>>>17:07:14.000000000 +1000
>>>>>>>+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30
>>>>>>>17:07:14.000000000 +1000
>>>>>>[...]
>>>>>>>@@ -158,14 +161,20 @@
>>>>>>> };
>>>>>>> [EMAIL PROTECTED],0 {
>>>>>> Hmm... what does @2,0 mean? :-O
>>>>>EBC chip select 2, offset 0.
>>>> Well, so this node is under some kind of local bus node -- that's good.
>>>>Didn't know that the spec allows commas after @...
>>>Well, now you do. I believe USB usually uses that format, too.
>> USB what, hosts or devices?
> Devices.
And what the comma-separated numbers mean there?
[...]
WBR, Sergei
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
