From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hong Xu Date: Mon, 01 Aug 2011 16:13:59 +0800 Subject: [U-Boot] [PATCH 1/2 V3] AT91: Makes AT91SAM9RL SoC build correctly against u-boot-atmel/master In-Reply-To: <1312185615.3635.105.camel@ubuntu> References: <1308107471-22295-1-git-send-email-hong.xu@atmel.com> <1312185615.3635.105.camel@ubuntu> Message-ID: <4E366047.3050908@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Reinhard, On 08/01/2011 04:00 PM, Reinhard Meyer wrote: > Dear Hong Xu, > > Rework for AT91SAM9RL SoC, makes it build again. > > arch/arm/include/asm/arch-at91/at91sam9rl_matrix.h | 121 +++++--------- > > When I compare at91sam9rl_matrix.h to at91sam9260_matrix.h there is only > one subtle difference: > > at91sam9260_matrix.h: > > struct at91_matrix { > u32 mcfg[16]; /* Master Configuration Registers */ > u32 scfg[16]; /* Slave Configuration Registers */ > u32 pras[16][2]; /* Priority Assignment Slave Registers */ > u32 mrcr; /* Master Remap Control Register */ > u32 filler[0x06]; > u32 ebicsa; /* EBI Chip Select Assignment Register */ > > at91sam9rl_matrix.h: > > struct at91_matrix { > u32 mcfg[16]; /* Master Configuration Registers */ > u32 scfg[16]; /* Slave Configuration Registers */ > u32 pras[16][2]; /* Priority Assignment Slave Registers */ > u32 mrcr; /* Master Remap Control Register */ > u32 filler[7]; > u32 ebicsa; /* EBI Chip Select Assignment Register */ > }; > > 1. Is it really filler[7] for the 9rl - can you verify with the data > sheet? Confirmed. ebicsa is at 0x120 for SAM9RL, but 0x11c for SAM9260. > 2. It seems there is a possibility to unify all those _matrix files into > one in the future (we are not going to do this now!) ? There are many differents among chips. For example, on SAM9260/SAM9G10 struct at91_matrix { u32 mcfg; /* Master Configuration Registers */ u32 scfg[5]; /* Slave Configuration Registers */ u32 filler[6]; u32 ebicsa; /* EBI Chip Select Assignment Register */ }; And for newer chips, some new fields are added. Can we keep current scheme and then have a look to see whether we have an elegant way to handle this? BTW, we're going to add some new chips soon. Thanks. BR, Eric