[U-Boot-Users] [PATCH 1/3] Initial OneNAND support

Hi
This patch supports OneNAND device on U-Boot. The most codes are based on OneNAND MTD in kernel.
For better performance I added 32-bytes aligned memcpy32. Pleae check it.
The OneNAND has been used for a long time. But not officially. This patch was tested apollon board. The apollon board patch is also sent soon.
Any comments are welcome.
Thank you, Kyungmin Park

Second patch
Thank you, Kyungmin Park

Third patch
Thank you, Kyungmin Park

Dear Kyungmin Park,
in message 001201c76623$2e7b9cd0$c7a3580a@swcenter.sec.samsung.co.kr you wrote:
This patch supports OneNAND device on U-Boot. The most codes are based on OneNAND MTD in kernel.
Your patches have a few cosing style issues (indentation not by TAB's, trailing white space). Please clean up and resubmet; see also http://www.denx.de/wiki/UBoot/CodingStyle
Also, please restrict your line length no around 70 characters or so.
And can you please add a GPL license header to onenand/onenand_bbt.c, include/linux/mtd/bbm.h
For better performance I added 32-bytes aligned memcpy32. Pleae check it.
Did you measure how much of performance this gains? Is it really worth the effort? In any case, the file needs a GPL license header.
Best regards,
Wolfgang Denk

Dear Wolfgang Denk,
This patch supports OneNAND device on U-Boot. The most codes are based on OneNAND MTD in kernel.
Your patches have a few cosing style issues (indentation not by TAB's, trailing white space). Please clean up and resubmet; see also http://www.denx.de/wiki/UBoot/CodingStyle
Thank you, I use the 'indent' programe to fix indentation
Also, please restrict your line length no around 70 characters or so.
Since its code based on kernel and consistent with kernel. it has almost same syntax.
And can you please add a GPL license header to onenand/onenand_bbt.c, include/linux/mtd/bbm.h
I added it.
For better performance I added 32-bytes aligned memcpy32. Pleae check it.
Did you measure how much of performance this gains? Is it really worth the effort? In any case, the file needs a GPL license header.
we can feel that it's more faster than before. OK I added GPL license
Thank you, Kyungmin Park

In message 000101c7669b$0e776c20$c7a3580a@swcenter.sec.samsung.co.kr you wrote:
resubmet; see also http://www.denx.de/wiki/UBoot/CodingStyle
Thank you, I use the 'indent' programe to fix indentation
You may want to use "Lindent -pcs" instead, see http://www.denx.de/wiki/UBoot/CodingStyle as mentioned above.
Also, please restrict your line length no around 70 characters or so.
Since its code based on kernel and consistent with kernel. it has almost same syntax.
So what?
For better performance I added 32-bytes aligned memcpy32. Pleae check it.
Did you measure how much of performance this gains? Is it really worth the effort? In any case, the file needs a GPL license header.
we can feel that it's more faster than before. OK I added GPL license
How much? 5%? 20%? 50%?
Best regards,
Wolfgang Denk

Also, please restrict your line length no around 70
characters or so.
Since its code based on kernel and consistent with kernel. it has almost same syntax.
So what?
To maintain easily. as mentioned it's the first version of OneNAND driver in kernel. it's code is almost same in kernel 2.6.15. After release I changed a lots of code. I will update it for OneNAND on U- Boot.
Indentation not by TABs, trailing white space.
I changed it using 's/^ /^ /g', 's/ $/$/g'.
For better performance I added 32-bytes aligned memcpy32. Pleae check it.
Did you measure how much of performance this gains? Is it really worth the effort? In any case, the file needs a
GPL license
header.
we can feel that it's more faster than before. OK I added
GPL license
How much? 5%? 20%? 50%?
Architecture optimized copy is fast about 3 times in OMAP 16xx series (ARM 9 core) in U-Boot
Here's test results memory copy (Unit: nsec) 96 MHz 192 MHz unsigned long * 189,440 ~ 192,000 158,720 ~ 160,000 architecture optimized copy 56,320 ~ 58,880 53,760 ~ 55, 040
where increment time is 2560 nsec in 96 MHz and 1280 nsec in 192 MHz
Thank you, Kyungmin Park

In message 002901c766a1$cf65edc0$c7a3580a@swcenter.sec.samsung.co.kr you wrote:
Indentation not by TABs, trailing white space.
I changed it using 's/^ /^ /g', 's/ $/$/g'.
Which is definitely not good enough.
Architecture optimized copy is fast about 3 times in OMAP 16xx series (ARM 9 core) in U-Boot
OK. Will the code work for non-ARM architectures?
Best regards,
Wolfgang Denk

Indentation not by TABs, trailing white space.
I changed it using 's/^ /^ /g', 's/ $/$/g'.
Which is definitely not good enough.
Architecture optimized copy is fast about 3 times in OMAP
16xx series
(ARM 9 core) in U-Boot
OK. Will the code work for non-ARM architectures?
Maybe not. I'm not famiar with other architectures. Now most boards which use OneNAND are ARM Arch. so I only consider it. Sorry. We have to consider other architetures.
We can only use it in ARM by adding __ARM__ definition in onenand_base.c, otherwise use its own memcpy
+#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, src, count);
return (void *) count; } +#endif
Thank you, Kyungmin Park

For better performance I added 32-bytes aligned memcpy32. Pleae check it.
Did you measure how much of performance this gains? Is it really worth the effort? In any case, the file needs a
GPL license
header.
we can feel that it's more faster than before. OK I added
GPL license
How much? 5%? 20%? 50%?
Architecture optimized copy is fast about 3 times in OMAP 16xx series (ARM 9 core) in U-Boot
Here's test results memory copy (Unit: nsec) 96 MHz 192 MHz unsigned long * 189,440 ~ 192,000 158,720 ~ 160,000 architecture optimized copy 56,320 ~ 58,880 53,760 ~ 55, 040
where increment time is 2560 nsec in 96 MHz and 1280 nsec in 192 MHz
On the issue of architecture specific memcpy()s. There appears to be an issue with the ppc optimized memcpy() in that it assumes alignment of both source and destination buffers. Our solution was to disable architecture specific memcpy() routines. We did however need the performance of a long word copy so we made our own memcpy() routine that we use during elf load, this isn't very elegant however.
It would be useful to have a generic C version of memcpy/memset/etc() for 8, 16 and 32 (maybe 64), bit architectures. Maybe a macro with a SIZE parameter would be suitable for generating the functions. The implementation would likely be very similar to your memcpy32() and it would be quite a bit easier to add support for unaligned pointers to a C version of memcpy() vs. modifying the asm code for each architecture.
Chris
participants (3)
-
Chris Morgan
-
Kyungmin Park
-
Wolfgang Denk