From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Sat, 27 Jan 2007 10:44:43 +0100 Subject: [U-Boot-Users] Atmel DataFlash hooks. References: <528646bc0701260044t56b5cfd6h98ac591f7edc02b9@mail.gmail.com><000001c7416f$fa61fed0$01c4af0a@atmel.com><528646bc0701261102u2f7e94b1k6dda4efd0bfb577a@mail.gmail.com><02eb01c74180$c4911410$01c4af0a@atmel.com><528646bc0701261227hb546f4fx72efde9caa23c1c6@mail.gmail.com><012801c74192$289ae920$01c4af0a@atmel.com><528646bc0701261440q4e4526dew2dc17339c438d7d3@mail.gmail.com><018c01c7419e$bf392520$01c4af0a@atmel.com> <528646bc0701261546p38084059x8461a781eb0af1fd@mail.gmail.com> Message-ID: <004801c741fb$5e8e76a0$01c4af0a@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Grant Likely wrote: > On 1/26/07, Ulf Samuelsson wrote: >>>> No, but you started off by saying you specifically are focusing on >>>> dataflash, >>>> and then you need to test on the primary target for the dataflash >>>> which is the AT91 series. >>> >>> Then I apologies and ask for forgiveness. I want to see some of the >>> crazy side cases removed from the generic routines (and replaced >>> with generic hooks where appropriate). >> >> Why? >> Have you done any cost benefit analysis to the rest of the community? >> What will the world gain by such a change? > > Simpler code, easier to maintain code, easier to add new storage > devices, easier to have boards with multiple different storage > technologies, smaller u-boot binaries. > > Let me flip the question around: Do you like the current > implementation where each storage technology (MMC, memmapped flash, > and DataFlash; see my reply to Wolfgang) has it's own set of hooks in > each memory access command? > > How about this: > 1. start with *not* changing the mmi and u-boot continues to pretend > that DataFlash and MMC devices are memmapped. I may not like it, but > I understand your position on this. > 2. add a common interface for non-RAM and non-memorymapped devices > that provides a single interface for commands like cp, md, bootm, etc > to find out if an address is 'special' and what routines it should > call to access them. > 3. First migrate memmapped flash devices to the new interface to prove > it is workable. > 4. Second migrate over either MMC or DataFlash devices; based on who > is able to provide test support (this does *not* touch the low level > code. It introduces a shim between the commands and the device > routines) > 5. Migrate the remaining hooks. At this point, all the command > functions should only have a single hook for access non-memmapped, > non-RAM devices. All commands should now work on all devices. ie. md > command can access MMC devices, something it cannot do now. > > Of course there is design work that needs to be done, but in this > stages approach, the first patch will show how the common interface is > designed. > Now you are getting there... This is a workable approach. >> >>> I should have couched it more in >>> those terms when I first brought it up. >>> >> >>> From my point of view, dataflash is the main case, and >> everything else is a side case. > > I only see it as a side case due to the way it is implemented. Now > that I've looked deeper into the other commands, the same argument > goes for MMC devices. If the implementation changes to use a common > interface for these similar devices then it's not a side case any > longer in my mind. > >> I do not see any benefit in changing the MMI for dataflash. >> I rather see changes which will make dataflash more similar >> in use to std parallell flash. >> In my u-boot I can compare dataflash to SDRAM etc. >> > > Fair enough > > Cheers, > g. Best Regards, Ulf Samuelsson ulf at atmel.com GSM: +46 (706) 22 44 57 Tel: +46 (8) 441 54 22 Fax: +46 (8) 441 54 29 Mail: Box 2033 174 02 Sundbyberg Visit: Kavalleriv?gen 24 174 58 Sundbyberg' Sweden