lkml.org 
[lkml]   [2011]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver
    On 5/21/2011 11:50 AM, Eric Biederman wrote:
    > On Sat, May 21, 2011 at 6:52 AM, Chris Metcalf <cmetcalf@tilera.com> wrote:
    >> Interesting! I did in fact assume that most tools that read or write
    >> eeproms would tend to be "batch" tools, i.e. they would read or write
    >> whatever it was they wanted, then exit; the tool we have that modifies this
    >> EEPROM is written like that, for example. It sounds like you're saying
    >> there are (or may be) tools that open the file descriptor and do writes to
    >> it, then don't exit or close the file descriptor, but expect the last write
    >> to have hit the device immediately. It's fair to say that since my
    >> suggested API does defer the last sector's worth of writes until the app
    >> exits, it potentially violates that assumption, so it's a bad idea.
    > Plus the other gigantic difference that I have seen very few eeproms
    > that can hold a sectors worth of data.
    >
    > My reading of this conversation is that you are confusing a configuration
    > eeprom with a nor flash boot device. That is a bit like confusing a yellow
    > sticky not with the Encyclopedia Britannica. They aren't at all the
    > same thing.

    Well, I don't think I'm confusing the two types of hardware, per se. The
    issue is that the hypervisor provides an API to Linux (or other operating
    systems) that attempts to make them look reasonably similar. In
    particular, for the SPI ROM, the hypervisor implicitly manages background
    reading of the sector data, doing a "diff" of new data to determine whether
    a sector erase is required, and deferring the actual sector write until the
    client attempts to write to a different sector. (This last feature is why
    an explicit "flush" is required.)

    This approach (unlike mtdchar) provides a "transparent" mode for accessing
    the SPI ROM. Users of our character driver don't need to know they are
    writing a flash device, don't need to worry about erasing/rewriting
    sectors, etc. We could potentially rework our boot ROM management tool to
    support the mtdchar API, but it would be a modest pain, particularly since
    we still have to support the normal file mode without "erase" ioctls, etc.,
    for use in the "cross-compiling" mode that we offer with this tool. And,
    another Tilera tool that stores data in the SPI ROM for bootup
    configuration would also have to be similarly reworked. And, if any of our
    customers have taken advantage of the part of the SPI ROM that is reserved
    for applications, they'd have to make that change as well. This seems like
    a problem. Plus, for what it's worth, it would make it impossible for us
    to use our tools on top of another OS, since they'd be dependent on a
    Linux-only interface.

    None of this is impossible to change, but my sense is that a basically
    trivial character device that makes use of the existing Tilera hypervisor's
    virtualization of the flash ROM should not be particularly problematic. It
    is true that it may not be worth grouping with other flash ROM character
    devices, since it has almost no "flash ROM" characteristics due to the
    hypervisor virtualization, but I will leave that up to Arnd. I'm happy to
    add some comments to the driver explaining what makes it different.

    I hope this adequately addresses your concerns.

    --
    Chris Metcalf, Tilera Corp.
    http://www.tilera.com




    \
     
     \ /
      Last update: 2011-05-23 22:13    [W:0.023 / U:0.408 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site