[U-Boot-Users] [PATCH 3/5] OneNAND support

Kyungmin Park kmpark at infradead.org
Mon Sep 10 03:14:01 CEST 2007


> ...
> > +#ifdef __ARM__
> > +extern void memcpy32(void *, void *, size_t);
> > +
> > +static void *memcpy(void *dest, const void *src, size_t count)
> > +{
> > +	if (count < 32) {
> > +		unsigned short *_s = (unsigned short *)(src);
> > +		unsigned short *_d = (unsigned short *)(dest);
> > +		count >>= 1;
> > +		while (count--)
> > +			*_d++ = *_s++;
> > +		return _d;
> > +	}
> > +
> > +	memcpy32(dest, (void *)src, count);
> > +
> > +	return (void *)count;
> > +}
> > +#endif
> 
> Why exactly do we need this? And why do we need an additonal  special
> function memcpy32?

It's for performance. Now ARM used the char-based memcpy. Even though it's working with current char-based memcpy, I want to use the
optimized memcpy.
And basically OneNAND uses the 16-bit buswidth so we don't sure the correct behavior in OneNAND BufferRAM if we use the char-based
memcpy.

Memcpy32 is 32-bytes aligned optimized. Since we know the memcpy usages in OneNAND driver, we guarantee the usage of memcpy32.

> 
> > +static const unsigned char ffchars[] = {
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	/* 16 */
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	/* 32 */
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	/* 48 */
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> > +	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,	/* 64 */
> > +};
> 
> Using a dynamic buffer and a memset() call in the init code may helpt
> to reduce the memory footprint. What do you think?

At first I want to sync between the linux OneNAND code and u-boot one.
The current code of u-boot patch is the first implementation of linux OneNAND.
There are a lot of works to sync.
So after committing of patches, I will modify it.

> 
> > +static unsigned short onenand_readw(void __iomem * addr)
> > +{
> > +	return readw(addr);
> > +}
> ...
> > +static void onenand_writew(unsigned short value, void __iomem * addr)
> > +{
> > +	writew(value, addr);
> > +}
> 
> If this is all you do, you should probably use an inline or a macro.

It's same reason as above.
In linux OneNAND, we can overwrite the readw and writew. But I'm now sure it's needed at u-boot.
	if (!this->read_word)
		this->read_word = onenand_readw;
	if (!this->write_word)
		this->write_word = onenand_writew;

> 
> > + * Get the device and lock it for exclusive access
> > + */
> > +static void onenand_get_device(struct mtd_info *mtd, int new_state)
> > +{
> > +	/* Do nothing */
> > +}
> ...
> > + * Deselect, release chip lock and wake up anyone waiting on the device
> > + */
> > +static void onenand_release_device(struct mtd_info *mtd)
> > +{
> > +	/* Do nothing */
> > +}
> 
> Inline? Macro?
> 

Also others are same. Some functions are don't needed at u-boot. But it was remained for easy adaptation from linux to u-boot.

Thank you,
Kyungmin Park





More information about the U-Boot mailing list