Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-12-16 Thread Macpaul Lin
Hi Ming-Dien

2010/12/16 Ming-Dien Chang :
> Hi, Macpaul
>
>> Yes, patch v5 only send the header file which the code is clean and might
>> no need to be modified before it has been reviewed.
>> Other patches will be send individually after they have be clean since the
>> patch might need to be revise in the future.
>> However, those continuous patches related to cpu core and boards which
>> might need be revised should not affect the "only" header file send out in
>> v5.
>
> I got confused for some things:
>
> 1. The v5 patch published so far is not complete, and other parts of v5
> patch will be released later !?

Yes, due to some code is under written. Patch v5 has released the most
basic header files right now.

> 2. Or, the header-only patch is applicable to the master tree according to
> the "Changes for v5" !?

No, only clean code which has been reviewed will be put into master tree or
nds32 tree. Those commits which has been accepted will go into nds32 tree
first, and then be merged into master tree.

>   However, neither the master tree nor nds32 frok contains the
> nds32-specific code.
>
> Thanks for your help.

It's my pleasure. :)

>
> Best Regards,
> Morgan
>


-- 
Best regards,
Macpaul Lin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-12-16 Thread Ming-Dien Chang
Hi, Macpaul

Yes, patch v5 only send the header file which the code is clean and might no
> need to be modified before it has been reviewed.
>
> Other patches will be send individually after they have be clean since the
> patch might need to be revise in the future.
> However, those continuous patches related to cpu core and boards which
> might need be revised should not affect the "only" header file send out in
> v5.
>
>
I got confused for some things:

1. The v5 patch published so far is not complete, and other parts of v5
patch will be released later !?
2. Or, the header-only patch is applicable to the master tree according to
the "Changes for v5" !?
  However, neither the master tree nor nds32 frok contains the
nds32-specific code.

Thanks for your help.

Best Regards,
Morgan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-12-14 Thread Macpaul Lin
Hi Ming-Dien,

2010/12/14 Ming-Dien Chang 

> Hi, Macpual
>
> On Thu, Nov 25, 2010 at 11:12 AM,  wrote:
>
> >
> > >   Is the series of patches (v1 to v5) increamental ?
> > >   Should I apply v1 first, and then v2, v3, till v5 ?
> > >   If so, what is base revision to which v1 patch is applied ?
> > >   Thanks for your help.
> > >   Morgan
> >
> > Let me explain for you, the patch version v1 to v5 just tagged for the
> > revision for the same single "patch".
> > So you just need to apply the latest patch you have. Please do not take
> > care about the v1-v4 patches.
> > The latest patch includes the latest update against to the main trunk
> > (master) source code.
> >
>
> The patch V5 includes only some  arch-depedent header files.
> Should I apply any previous patches ?
>
>
Yes, patch v5 only send the header file which the code is clean and might no
need to be modified before it has been reviewed.

Other patches will be send individually after they have be clean since the
patch might need to be revise in the future.
However, those continuous patches related to cpu core and boards which might
need be revised should not affect the "only" header file send out in v5.

If you really wan't to try the prior patches, you could try patch v4.
However, I suggest do not do that because if you develop your u-boot code
based on NDS32 patch v4,
you will have a lot of clean up work to do later. The more clean up work,
the more pain of your work and your company will be suffered. ;-p.

Otherwise, if your company doesn't want to open your u-boot's source code
nor want to be include in the u-boot main source tree.
Or you just want to try something with NDS32 "just" worked.
You can apply patch v3 or patch v4 should be  okay.

-- 
Best regards,
Macpaul Lin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-12-14 Thread Ming-Dien Chang
Hi, Macpual

On Thu, Nov 25, 2010 at 11:12 AM,  wrote:

>
> >   Is the series of patches (v1 to v5) increamental ?
> >   Should I apply v1 first, and then v2, v3, till v5 ?
> >   If so, what is base revision to which v1 patch is applied ?
> >   Thanks for your help.
> >   Morgan
>
> Let me explain for you, the patch version v1 to v5 just tagged for the
> revision for the same single "patch".
> So you just need to apply the latest patch you have. Please do not take
> care about the v1-v4 patches.
> The latest patch includes the latest update against to the main trunk
> (master) source code.
>

The patch V5 includes only some  arch-depedent header files.
Should I apply any previous patches ?


If you have furthor questions, please reply on the mailing list.
> Hope we can work this out together.
>
> >>  On Fri, Nov 19, 2010 at 1:51 PM, Macpaul Lin <
> macp...@andestech.com> wrote:
>
>
> >>  This patch add generic header files support for nds32
> architecture.
> >>  Cache, ptregs, data type and other definitions are
> included.
>
> >>  NDS32 is a new 32-bit RISC architecture invented by
> andestech.com.
>
> >>  NDS32 also provide N9, N10, N12 different CPU core families
> for soft-core
> >>  and hard-core SoC design.
>
> >>  Note:
> >>   Empty headers such as config.h, memory.h, processor.h are
> necessary for
> >>   compiling some device drivers.
> >>   Otherwise those drivers won't be build.
>
> Best regards,
> Macpaul Lin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-11-24 Thread Macpaul Lin
> From: Morgan 張明鈿 [mailto:mingdien.ch...@gmail.com]
> Sent: Wednesday, November 24, 2010 4:52 PM
> To: Macpaul Chih-Pin Lin(林智斌)
> Subject: Re: [U-Boot] [PATCH v5] nds32: Add NDS32 architecture support
>(header files)

> Hi, Macpaul
> I noticed the patches in the U-Boot mailing list for the nds32
architecture which I
> am trying to port.

Hi, Morgan,

I'm glad to see you have noticed that the patches commit to u-boot mainline
is undergoing.
I also guess the old andesboot (prior version of u-boot) we've provided was
not enough for your purpose.

1st, please add "u-boot@lists.denx.de" into the CC list on each e-mail
trasaction so that every developer of u-boot could involve the disscussion
and help you.

2nd, I'm curious that your company or organization might be one of our
customers, could you tell me whom you're working for?
So that our company could provide you better service on u-boot related
issues.

3rd, because every developer on u-boot project is busy doing code revise for
ARM arch in recent. So I invite you to help on code review on the mailing
list.
Because your help on code review, those patches will be accepted ASAP to the
u-boot project.
Just test the patches and reply the patch to the mailing list with
"Acked-by: mingdien.ch...@gmail.com" could help,

> Is the series of patches (v1 to v5) increamental ?
> Should I apply v1 first, and then v2, v3, till v5 ?
> If so, what is base revision to which v1 patch is applied ?
> Thanks for your help.
> Morgan

Let me explain for you, the patch version v1 to v5 just tagged for the
revision for the same single "patch".
So you just need to apply the latest patch you have. Please do not take care
about the v1-v4 patches.
The latest patch includes the latest update against to the main trunk
(master) source code.

If you have furthor questions, please reply on the mailing list.
Hope we can work this out together.
>> On Fri, Nov 19, 2010 at 1:51 PM, Macpaul Lin 
wrote:

>> This patch add generic header files support for nds32 architecture.
>> Cache, ptregs, data type and other definitions are included.
>> NDS32 is a new 32-bit RISC architecture invented by andestech.com.
 >> NDS32 also provide N9, N10, N12 different CPU core families for
soft-core
>> and hard-core SoC design.
>> Note:
>> Empty headers such as config.h, memory.h, processor.h are necessary for
>> compiling some device drivers.
>> Otherwise those drivers won't be build.
Best regards,
Macpaul Lin

-- 
Best regards,
Macpaul Lin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v5] nds32: Add NDS32 architecture support (header files)

2010-11-18 Thread Macpaul Lin
This patch add generic header files support for nds32 architecture.
Cache, ptregs, data type and other definitions are included.

NDS32 is a new 32-bit RISC architecture invented by andestech.com.

NDS32 also provide N9, N10, N12 different CPU core families for soft-core
and hard-core SoC design.

Note:
  Empty headers such as config.h, memory.h, processor.h are necessary for
  compiling some device drivers.
  Otherwise those drivers won't be build.

Signed-off-by: Macpaul Lin 
---
Changes for v1:
   - First commit of nds32 arch to u-boot, add SoC ag101, adp-ag101 into u-boot.
Changes for v2:
   - Clean up coding style.
   - Reorganize code of SoC ag101 from a320.
Changes for v3:
   - Clean up coding style.
   - Reordering and reduce the size and patches.
Changes for v4:
   - Clear up for Patch v3.
   - Remove code that haven't used in the system.
   - Commit header files only for easier code review.
Changes for v5:
   - Update changes against the change after master tree (v2010.12-rc1).
   - Fix upper case definitions in cache.h.
   - Support GD_FLG_ENV_READY and env_buf vars in nds32 global_data.h.
   - Add readsb, writesb functions into io.h.

 arch/nds32/include/asm/bitops.h   |  150 
 arch/nds32/include/asm/byteorder.h|   36 +++
 arch/nds32/include/asm/cache.h|   51 
 arch/nds32/include/asm/config.h   |   26 ++
 arch/nds32/include/asm/global_data.h  |   82 +++
 arch/nds32/include/asm/io.h   |  408 +
 arch/nds32/include/asm/mach-types.h   |   29 +++
 arch/nds32/include/asm/memory.h   |   19 ++
 arch/nds32/include/asm/posix_types.h  |   84 +++
 arch/nds32/include/asm/processor.h|   25 ++
 arch/nds32/include/asm/ptrace.h   |   22 ++
 arch/nds32/include/asm/ptregs.h   |   82 +++
 arch/nds32/include/asm/string.h   |   57 +
 arch/nds32/include/asm/types.h|   67 ++
 arch/nds32/include/asm/u-boot-nds32.h |   47 
 arch/nds32/include/asm/u-boot.h   |   69 ++
 arch/nds32/include/asm/unaligned.h|   31 +++
 17 files changed, 1285 insertions(+), 0 deletions(-)
 create mode 100644 arch/nds32/include/asm/bitops.h
 create mode 100644 arch/nds32/include/asm/byteorder.h
 create mode 100644 arch/nds32/include/asm/cache.h
 create mode 100644 arch/nds32/include/asm/config.h
 create mode 100644 arch/nds32/include/asm/global_data.h
 create mode 100644 arch/nds32/include/asm/io.h
 create mode 100644 arch/nds32/include/asm/mach-types.h
 create mode 100644 arch/nds32/include/asm/memory.h
 create mode 100644 arch/nds32/include/asm/posix_types.h
 create mode 100644 arch/nds32/include/asm/processor.h
 create mode 100644 arch/nds32/include/asm/ptrace.h
 create mode 100644 arch/nds32/include/asm/ptregs.h
 create mode 100644 arch/nds32/include/asm/string.h
 create mode 100644 arch/nds32/include/asm/types.h
 create mode 100644 arch/nds32/include/asm/u-boot-nds32.h
 create mode 100644 arch/nds32/include/asm/u-boot.h
 create mode 100644 arch/nds32/include/asm/unaligned.h

diff --git a/arch/nds32/include/asm/bitops.h b/arch/nds32/include/asm/bitops.h
new file mode 100644
index 000..f658a03
--- /dev/null
+++ b/arch/nds32/include/asm/bitops.h
@@ -0,0 +1,150 @@
+/*
+ * Copyright 1995, Russell King.
+ * Various bits and pieces copyrights include:
+ *  Linus Torvalds (test_bit).
+ *
+ * Copyright (C) 2010 Andes Technology Corporation
+ * Shawn Lin, Andes Technology Corporation 
+ *
+ * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
+ *
+ * Please note that the code in this file should never be included
+ * from user space.  Many of these are not implemented in assembler
+ * since they would be too costly.  Also, they require priviledged
+ * instructions (which are not available from user mode) to ensure
+ * that they are atomic.
+ */
+
+#ifndef __ASM_NDS_BITOPS_H
+#define __ASM_NDS_BITOPS_H
+
+#ifdef __KERNEL__
+
+#define smp_mb__before_clear_bit() do { } while (0)
+#define smp_mb__after_clear_bit()  do { } while (0)
+
+/*
+ * Function prototypes to keep gcc -Wall happy.
+ */
+extern void set_bit(int nr, volatile void * addr);
+
+static inline void __set_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr >> 3] |= (1U << (nr & 7));
+}
+
+extern void clear_bit(int nr, volatile void * addr);
+
+static inline void __clear_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr >> 3] &= ~(1U << (nr & 7));
+}
+
+extern void change_bit(int nr, volatile void * addr);
+
+static inline void __change_bit(int nr, volatile void *addr)
+{
+   ((unsigned char *) addr)[nr >> 3] ^= (1U << (nr & 7));
+}
+
+extern int test_and_set_bit(int nr, volatile void * addr);
+
+static inline int __test_and_set_bit(int nr, volatile void *addr)
+{
+   unsigned int mask = 1 << (nr & 7);
+   unsigned int oldval;
+
+   oldval = ((unsigned char *) addr)[nr >> 3];
+   ((unsigned char *) addr)[nr >> 3] = oldval | mask;
+   return oldval & mask;
+}
+
+extern in