[U-Boot] AT91 Rework

[U-Boot] AT91 Rework

[Jens Scharsig]

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

[U-Boot] AT91 Rework

[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)
...

[U-Boot] AT91 Rework

[Wolfgang Denk]

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

-- 
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 at denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.

[U-Boot] AT91 Rework

[Jens Scharsig]

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

[U-Boot] AT91 Rework

[Wolfgang Denk]

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:
> 
> 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

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

-- 
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 at denx.de
"Never face facts; if you do, you'll never get up in the morning."
- Marlo Thomas

[U-Boot] AT91 Rework

[Jens Scharsig]

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

[U-Boot] AT91 Rework

[Wolfgang Denk]

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 at denx.de
There's another way to survive.  Mutual trust -- and help.
	-- Kirk, "Day of the Dove", stardate unknown