Re: powerpc_flash_init(), wtf!?

Segher Boessenkool
2007-05-03T18:08:31Z

>>> NOR flashes are at the same level as the "memory" node (where
>>> else you
>>> expect them to appear I wonder?).
>
>> The "memory" node doesn't describe the RAM devices;
>> it describes the RAM address space, instead. You can
>> have separate nodes for the actual devices.
>
> If you can remember our prior discussion, the "rom" nodes don't
> describe "the actual devices" as well, only their mapping into the
> address space. ;-)

I don't remember that no. And having a node for the
"ROM address space" isn't useful in the same way as
having one for the "RAM address space" is -- flash
memory is not a resource you randomly hand out to
anyone who wants a piece. You also need to know some
_specifics_ about a certain ROM device before you can
map it into CPU address space properly.

>> Now for ROM/flash/NVRAM, nodes _can_ appear directly
>> under the root, but only if that is where they belong
>> on your platform (i.e., they sit directly on the "system
>> bus" (whatever that means on your platform); on most
>> platforms though, such devices are connected via some
>> I/O busses, so the nodes should appear under their
>> respective controllers.
>
> Yeah, you're right here, and I've probably misunderstood what
> "memory" node was. In fact, the flash in my system resides on the same
> local bus as RAM, so the proper place would be behind the "lbc" (or
> whatever -- it doesn't exist as yet) node on the "soc" bus. Do you
> think I need to go and document it as well for such cause? :-]

If the "lbc" isn't software visible, you can/should put
the RAM/ROM nodes directly under the SoC node.

This is all just standard considerations, so I don't think
you need to document it separately no. An example device
tree will help other implementors using your SoC create a
proper device tree, of course.

>> Most "north bridges" have some bits that enable
>> translation of accesses in the "low bios" area to
>> the 4GB-minus-a-bit area. There are many variations
>> and it all is a big mess :-)
>
> Human perversion knows no limits. O:-)

Well it's note like there aren't any groovy things on
some PowerPC systems, but x86 definitely wins :-)

>> Now, back to the case at hand -- it would be nice to
>> have a platform-independent way to probe the simple
>> case -- a single direct-mapped device -- but it isn't
>> obvious how to make that not clash with the not-so-simple
>> cases. A helper function that does the work but is
>> only called by the platforms that want it would do, I
>> suppose?
>
> It probably doesn't even worth a helper (since out of those 15
> lines, 6 were pretty useless anyway)

Sure -- but since it is such a common device to have (a
simple NOR boot flash), it would be nice to avoid any
code duplication. Compare to the serial port and RTC
situation.

Segher