[U-Boot] [PATCH v3] Add support for boards where the NOR FLASH is not memory-mapped

[Stefan Roese]

Hi Ulf,

On Friday 16 January 2009, Ulf Samuelsson wrote:
> tor 2008-12-11 klockan 12:11 +0100 skrev Stefan Roese:
> > This patch adds the CONFIG_FLASH_NOT_MEM_MAPPED define which can be
> > used on boards where the NOR FLASH is not memory-mapped and
> > special accessor functions are needed to access the NOR FLASH.
> > This affects the memory commands (cmd_mem.c) and the environment
> > (env_flash.c).
> >
> > Boards using CONFIG_FLASH_NOT_MEM_MAPPED need to additionally specify
> > CONFIG_FLASH_BASE and CONFIG_FLASH_END so that the NOR FLASH region
> > can be detected.
>
> If I interpret Wolfgang and others correctly,
> NOR FLASH which does not support random access is STORAGE
> and should not be accessible using memory commands,
> because it makes the commands harder to maintain.

I don't think that Wolfgang has ever said such a thing. What he (and others, 
including me) have said is that FLASH which is not memory mapped by its 
technology should be handled as storage media. This includes FLASH 
technologies like SPI and NAND. It definitely doesn't include NOR which is 
(usually) memory mapped accessable.

We're seeing here a board which has NOR FLASH but has some issues inside the 
SoC external bus interface making it impossible to access anything on the 
external bus memory mapped. So this is not a problem of the NOR FLASH itself 
but a problem with the SoC. And my patch is a workaround for this board (and 
perhaps others with the same issue with NOR FLASH) to access NOR FLASH again 
with the common U-Boot memory commands.

> Logically, You should therefore define an "nf" command or similar
> which accesses the memory in the same way as other "storage" do.

A new command set for this "broken" external bus interface? I don't think this 
is a good idea.

> Personally, I think it is MUCH cleaner to keep the memory
> command and just call a function
>
> 	srcdscr = translate(srcaddr);
> 	dstdscr = translate(dstaddr);
> 	while(requested_size > 0) {
> 		copied = memcpydscr(srcdscr,dstdscr, requested_size);
> 		if((copied == 0) && (requested_size > 0) {
> 			// Error handling
> 		}
> 		requested_size -= copied;
> 	}
>
> Each memory technology could register a translation driver
> and will parse the argument and decide if it is
> the "owner" of this argument, and if so, it will
> return a pointer to a descriptor.
> If not, the argument is passed on to the next
> translation driver until caught.
>
> During the copy, the src memory driver will read sectors
> and cache them allowing the dst memory driver
> to treat the src memory as RAM.
> At the end of the command, any cache contents are invalidated.
>
> The advantage of this, is that once the memory driver is
> written it will be fairly easy to support
> new memory technology without having to change the
> commands themselves.
>
> I know it was shot down 1-2 years, ago but so were other
> ideas which now has been implemented in U-boot,
> so I think we should revisit this.

I don't really want to start a new discussion on this right now. Personally 
I'm pretty content with the current way non-NOR FLASH devices are handled in 
U-Boot.

> If extending the memory commands this way, is allowed
> after NAKing future extensions for dataflash,
> then the decision process is clearly flawed.

Again, I think you are comparing apples with oranges. My patch addresses a 
problem which is similar to using dataflash with the common memory commands. 
But it's still using NOR FLASH. And I don't think that introducing a new 
command set for such a broken external bus interface is a good idea.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================