Hi Wolfgang,
2011/4/7 Wolfgang Denk <w...@denx.de>:
Dear Macpaul Lin,
>> Add generic header files support for nds32 architecture.
>> Cache, ptregs, data type and other definitions are included.
>>
>> Signed-off-by: Macpaul Lin <macp...@andestech.com>
>
> Checkpatch complains a lot about "do not add new typedefs".
Indeed, but this seems is special for Linux Kernel,
I've checked some of the "typedefs" from other architecture code in u-boot.
Most of them are specific for u-boot only.
Even GD is one of them.
I did check typedefs one by one by myself in hand and eye checking.
If some thing is not suitable for using "typedefs" please let me know.
> ...
>> +#define PTREGS(reg) [reg]
>
> This also triggers an erro-r from checkpatch, and indeed this is a
> strange define.
It was strange for me, too.
However, it looks like I must use PTREGS define for ptregs for API
compatibility.
Please refer to the ARM code and MIPS, etc.
> +#define R0 uregs[1] /* R0 */
>> +#define R1 uregs[2]
>> +#define R2 uregs[3]
>> +#define R3 uregs[4]
>> +#define R4 uregs[5]
>> +#define R5 uregs[6]
>> +#define R6 uregs[7]
>> +#define R7 uregs[8]
>> +#define R8 uregs[9]
>> +#define R9 uregs[10]
>> +#define R10 uregs[11]
>> +#define R11 uregs[12]
>> +#define R12 uregs[13]
>> +#define R13 uregs[14]
>> +#define R14 uregs[15]
>> +#define R15 uregs[16]
>> +#define R16 uregs[17]
>> +#define R17 uregs[18]
>> +#define R18 uregs[19]
>> +#define R19 uregs[20]
>> +#define R20 uregs[21]
>> +#define R21 uregs[22]
>> +#define R22 uregs[23]
>> +#define R23 uregs[24]
>> +#define R24 uregs[25]
>> +#define R25 uregs[26]
>> +#define R26 uregs[27]
>> +#define R27 uregs[28]
>> +#define FP uregs[29] /* R28 */
>> +#define GP uregs[30] /* R29 */
>> +#define RA uregs[31] /* R30 */
>> +#define SP uregs[32] /* R31 */
>> +#define D0HI uregs[33]
>> +#define D0LO uregs[34]
>> +#define D1HI uregs[35]
>> +#define D1LO uregs[36]
>> +#define PSW uregs[37] /* IR0 */
>> +#define PC uregs[38] /* PC */
>
> NAK. Please use a C struct instead.
Other architecture use specific ARM_XXX_R0 or MIPS_XXX _R.
Since most of NDS32 registers could be used as general register, hence
we have such format in define.
If you have better idea, please give me a suggestion of the code to
the correspoded
And I think this part is specific for the API to ptregs.h.
Other architecture gose the similar format instead C structure.
If use C structure to present a set of CPU registers is adapable for
ptregs related API is workable, please give me such a hint and I will
try.
However, the define of PC or PSW for ptregs related feature I guess it
is required somehow.
Please give a suggestion if my knowledge of ptregs related APIs is wrong.
> ...
>> diff --git a/arch/nds32/include/asm/u-boot.h
>> b/arch/nds32/include/asm/u-boot.h
>> new file mode 100644
>> index 0000000..fafe4e4
>> --- /dev/null
>> +++ b/arch/nds32/include/asm/u-boot.h
>> @@ -0,0 +1,63 @@
>> +/*
>> + * (C) Copyright 2002
>> + * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
>> + * Marius Groeger <mgroe...@sysgo.de>
>> + *
>> + * Copyright (C) 2011 Andes Technology Corporation
>> + * Copyright (C) 2010 Shawn Lin (nobuh...@andestech.com)
>> + * Copyright (C) 2011 Macpaul Lin (macp...@andestech.com)
> ...
>> +#ifndef _U_BOOT_H_
>> +#define _U_BOOT_H_ 1
>> +
>> +#include <environment.h>
>> +
>> +typedef struct bd_info {
>> + int bi_baudrate; /* serial console baudrate */
>> + unsigned long bi_ip_addr; /* IP Address */
>> + unsigned char bi_enetaddr[6]; /* Ethernet adress */
>> +
>> + env_t *bi_env;
>> + unsigned long bi_arch_number; /* unique id for this board */
>> + unsigned long bi_boot_params; /* where this board expects params */
>> +
>> + unsigned long bi_memstart; /* start of DRAM memory */
>> + unsigned long bi_memsize; /* size of DRAM memory in bytes */
>> + unsigned long bi_flashstart; /* start of FLASH memory */
>> + unsigned long bi_flashsize; /* size of FLASH memory */
>> + unsigned long bi_flashoffset; /* reserved area for startup monitor */
>> +
>> + struct /* RAM configuration */
>> + {
>> + unsigned long start;
>> + unsigned long size;
>> + } bi_dram[CONFIG_NR_DRAM_BANKS];
>> +} bd_t;
>
> I wonder which part of this file would be (C) by any of the folks
> listed above?
Because I'm not in the office (this is not office hour in asia).
I'll check it in the office tommorrow.
Thanks a lot.
--
Best regards,
Macpaul Lin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
