From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Wed, 31 Jan 2007 20:46:21 -0600 Subject: [U-Boot-Users] Atmel DataFlash hooks. In-Reply-To: <20070201000604.AF6C0353A8A@atlas.denx.de> References: <20070201000604.AF6C0353A8A@atlas.denx.de> Message-ID: <45C1547D.4060009@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: >> Then please continue to explain why, when you are doing exactly >> the same manouvers, but use a serial flash, you do not need the >> commands. >> > > Because these devices are not directly addressable in the processors > address space, i. e. they are not memory. > > Everything is fine as long as the "md" command in U-Boot and the "md" > command at my BDI2000's telnet prompt show the same results for the > same address ranges. When this is NOT the case, something is broken. > Here, it is the U-Boot implementation. > I guess I am OK with either implementation. I think just because BDI is not capable of handling any address space besides the processor address space should not mean we should so restrictive of command line of U-Boot. I think address space tags that I proposed yesterday could remove the confusion of what address the command is referring to and it is easy to explain that a BDI could only access untagged address space directly and everything else are indirectly accessible memory. This would also enable us to use paged memory mapped to a small window in processor address space seamlessly. Anyway, I think either approach is valid and usable. There are pros and cons with either scheme. I think it might be easier to educate the user with one set of commands as opposed to user having to decide which one of several read/write commands should be applicable. >> The concept to map an address is not at all hard to explain. >> Even so, I have never had the question in over 100 projects. >> > > For me this is a very important issue: when U-Boto and a hardware > debugger start behaving differently, I consider this a serious > problem. U-Boot is a boot loader, and as such mostly a hardware debug > tool. > I see your point. However, with a hardware debugger you are not currently able to mmc data directly and so you could not be able to access mmc:0x00112233 either because "mmc:0x00112233" is not an address that would be valid for BDI. So, I see no difference. It is really mostly a matter of style rather than function. Having the capability of u-boot memory commands to access different address spaces is a convenience feature. When such feature is not available the read/write commands will bring a chunk to ram and it will be processed using memory commands again so first one would allow the two operations combined but not a huge gain or loss either way. Having said all that, I will concluded that either way is OK for me as long as we maintain consistent architecture. Tolunay