[U-Boot] AT91 Rework

Dear Wolfgang Denk,
We discussed the AT91 defs replaced by C structures. I have checked the AT91 and the AT91RM9200 tree. I have planned the following procedure:
1. Add the CONFIG_AT_LEGACY to all affected boards (until the board is updated) 2. Put an warinig to all files that use old defs 3. enclose the old def's with #ifdef CONFIG_AT_LEGACY 4. Add new C stuctures to header files 5. update affected common and driver files 6. next steps t.b.d
An additional aim of the revision should be the union of the AT91 and AT91RM9200 tree. Some part like UART, SPI; PIO and so one are the same. Only a lot of devices like MAC are different. But I can't see, when this work will be done.
Please tell me, where you think it makes sense to provide an patch
Best regards
Jens Scharsig

Dear Wolfgang Denk,
what you are mean to the following code snippet
it decrpipts then AT91 timercontroller and lot of TC configuration bits
I am on the right way?
Best regards
Jens Scharsig
...
typedef struct at91_tcc { ulong ccr; /* 0x00 Channel Control Register */ ulong cmr; /* 0x04 Channel Mode Register */ ulong reserved1[2]; ulong cv; /* 0x10 Counter Value */ ulong ra; /* 0x14 Register A */ ulong rb; /* 0x18 Register B */ ulong rc; /* 0x1C Register C */ ulong sr; /* 0x20 Status Register */ ulong ier; /* 0x24 Interrupt Enable Register */ ulong idr; /* 0x28 Interrupt Disable Register */ ulong imr; /* 0x2C Interrupt Mask Register */ ulong reserved3[4]; } at91_tcc_t;
#define AT91_TC_CCR_CLKEN ((ulong) 0x00000001) #define AT91_TC_CCR_CLKDIS ((ulong) 0x00000002) #define AT91_TC_CCR_SWTRG ((ulong) 0x00000004) ...
typedef struct at91_tc { at91_tcc_t tc[3]; /* 0x00 TC Channel 0-2 */ ulong bcr; /* 0xC0 TC Block Control Register */ ulong bmr; /* 0xC4 TC Block Mode Register */ } at91_tc_t;
... #define AT91_TC_BMR_TC0XC0S_TCLK0 ((ulong) 0x00000000) #define AT91_TC_BMR_TC0XC0S_NONE ((ulong) 0x00000001) #define AT91_TC_BMR_TC0XC0S_TIOA1 ((ulong) 0x00000002) #define AT91_TC_BMR_TC0XC0S_TIOA2 ((ulong) 0x00000003)
#define AT91_TC_BMR_TC1XC1S_TCLK1 ((ulong) 0x00000000) #define AT91_TC_BMR_TC1XC1S_NONE ((ulong) 0x00000004) #define AT91_TC_BMR_TC1XC1S_TIOA0 ((ulong) 0x00000008) #define AT91_TC_BMR_TC1XC1S_TIOA2 ((ulong) 0x0000000C)
#define AT91_TC_BMR_TC2XC0S_TCLK2 ((ulong) 0x00000000) #define AT91_TC_BMR_TC2XC0S_NONE ((ulong) 0x00000010) #define AT91_TC_BMR_TC2XC0S_TIOA0 ((ulong) 0x00000020) #define AT91_TC_BMR_TC2XC0S_TIOA1 ((ulong) 0x00000030) ...

Dear Jens,
In message hcspnl$oud$1@ger.gmane.org you wrote:
what you are mean to the following code snippet
it decrpipts then AT91 timercontroller and lot of TC configuration bits
I am on the right way?
Thanks - yes you are.
Umm... you are quite active for AT91 now - the position of the AT91 is still orphaned; did you ever think about volunteering?
typedef struct at91_tcc { ulong ccr; /* 0x00 Channel Control Register */ ulong cmr; /* 0x04 Channel Mode Register */ ulong reserved1[2]; ulong cv; /* 0x10 Counter Value */ ulong ra; /* 0x14 Register A */ ulong rb; /* 0x18 Register B */ ulong rc; /* 0x1C Register C */ ulong sr; /* 0x20 Status Register */ ulong ier; /* 0x24 Interrupt Enable Register */ ulong idr; /* 0x28 Interrupt Disable Register */ ulong imr; /* 0x2C Interrupt Mask Register */ ulong reserved3[4]; } at91_tcc_t;
I recomment to make this "u32" instead of "ulong".
#define AT91_TC_CCR_CLKEN ((ulong) 0x00000001) #define AT91_TC_CCR_CLKDIS ((ulong) 0x00000002) #define AT91_TC_CCR_SWTRG ((ulong) 0x00000004)
These casts should not be needed:
#define AT91_TC_CCR_CLKEN 1 #define AT91_TC_CCR_CLKDIS 2 #define AT91_TC_CCR_SWTRG 4
typedef struct at91_tc { at91_tcc_t tc[3]; /* 0x00 TC Channel 0-2 */ ulong bcr; /* 0xC0 TC Block Control Register */ ulong bmr; /* 0xC4 TC Block Mode Register */ } at91_tc_t;
again, please use "u32" instead of "ulong".
#define AT91_TC_BMR_TC0XC0S_TCLK0 ((ulong) 0x00000000) #define AT91_TC_BMR_TC0XC0S_NONE ((ulong) 0x00000001) #define AT91_TC_BMR_TC0XC0S_TIOA1 ((ulong) 0x00000002) #define AT91_TC_BMR_TC0XC0S_TIOA2 ((ulong) 0x00000003)
#define AT91_TC_BMR_TC1XC1S_TCLK1 ((ulong) 0x00000000) #define AT91_TC_BMR_TC1XC1S_NONE ((ulong) 0x00000004) #define AT91_TC_BMR_TC1XC1S_TIOA0 ((ulong) 0x00000008) #define AT91_TC_BMR_TC1XC1S_TIOA2 ((ulong) 0x0000000C)
#define AT91_TC_BMR_TC2XC0S_TCLK2 ((ulong) 0x00000000) #define AT91_TC_BMR_TC2XC0S_NONE ((ulong) 0x00000010) #define AT91_TC_BMR_TC2XC0S_TIOA0 ((ulong) 0x00000020) #define AT91_TC_BMR_TC2XC0S_TIOA1 ((ulong) 0x00000030)
again, please drop at least the parens and the casts.
Best regards,
Wolfgang Denk

Dear Wolfgang Denk,
Umm... you are quite active for AT91 now - the position of the AT91 is still orphaned; did you ever think about volunteering?
At the moment I'm work for different AT91 (AT91RM9200, AT91SAM9260 and AT91SAM9360) in timeslot mode. But I am fully costumer driven, so that it can be, i must switch to complette a other system like PIC and so on or back to windows.
I recomment to make this "u32" instead of "ulong".
I will replace this.
again, please drop at least the parens and the casts.
It will be removed
Best regards,
Jens Scharsig

Dear Jens Scharsig,
In message 4AF1D190.1010800@scharsoft.de you wrote:
We discussed the AT91 defs replaced by C structures. I have checked the AT91 and the AT91RM9200 tree. I have planned the following procedure:
- Add the CONFIG_AT_LEGACY to all affected boards (until the board is updated)
- Put an warinig to all files that use old defs
- enclose the old def's with #ifdef CONFIG_AT_LEGACY
- Add new C stuctures to header files
- update affected common and driver files
- next steps t.b.d
THis sounds good to me.
An additional aim of the revision should be the union of the AT91 and AT91RM9200 tree. Some part like UART, SPI; PIO and so one are the same. Only a lot of devices like MAC are different. But I can't see, when this work will be done.
I understand this. Let's focus on what you can do now. Evey bit of improvement is highly welcome.
Best regards,
Wolfgang Denk

Dear Wolfgang Denk,
i still working on replacing AT91 defs by C structures.
But I have a problem with lowlevel_init.s files Both AT91 and AT91RM9200 use the register defines here. The C header files have a
#ifndef __assembly ... #endif
to prevent assembler error.
My Question:
Should we move the handfull defines used by assembly code to a separate header file (lowlevel.h), or to the front of the lowlevel_init.s files, or define it a #ifndef __assembly ... #endif block
Best regards
Jens Scharsig

Dear Jens Scharsig,
In message 4AF5CC8F.7040602@scharsoft.de you wrote:
But I have a problem with lowlevel_init.s files Both AT91 and AT91RM9200 use the register defines here. The C header files have a
#ifndef __assembly ... #endif
to prevent assembler error.
My Question:
Should we move the handfull defines used by assembly code to a separate header file (lowlevel.h), or to the front of the lowlevel_init.s files, or define it a #ifndef __assembly ... #endif block
I'm not too familiar with that code, so I tend to trust you who knows it better than me - just apply common sense. If in doubt, go for the minimal invasive changes - this is something we can clean up later easily, too.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de There's another way to survive. Mutual trust -- and help. -- Kirk, "Day of the Dove", stardate unknown
participants (2)
-
Jens Scharsig
-
Wolfgang Denk