From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= <andreas.devel@googlemail.com>
Date: Mon, 02 Jul 2012 11:47:55 +0200
Subject: [U-Boot] [PATCH v2] arm : Atmel : add at91sam9x5ek board support
In-Reply-To: <4FF15D75.70003@gmail.com>
References: <1341200122-18329-1-git-send-email-voice.shen@atmel.com>
	<4FF14744.7040802@googlemail.com> <4FF15D75.70003@gmail.com>
Message-ID: <4FF16E4B.4020601@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 02.07.2012 10:36, Bo Shen wrote:
> Hi Andreas,
> 
> On 7/2/2012 15:01, Andreas Bie?mann wrote:
>> Dear Bo Shen,
>>
>> On 02.07.12 05:35, Bo Shen wrote:

<snip>

>>> diff --git a/drivers/serial/atmel_usart.h b/drivers/serial/atmel_usart.h
>>> index 7e4b2c9..ad1d9f0 100644
>>> --- a/drivers/serial/atmel_usart.h
>>> +++ b/drivers/serial/atmel_usart.h
>>> @@ -37,8 +37,8 @@ typedef struct atmel_usart3 {
>>>       u32    rtor;
>>>       u32    ttgr;
>>>       u32    reserved0[5];
>>> -    u32    fidi;
>>> -    u32    ner;
>>> +    u32    fidi;        /* cidr for dbgu */
>>> +    u32    ner;        /* exid for dbgu */
>> NAK
>>
>>>       u32    reserved1;
>>>       u32    ifr;
>>>       u32    man;
>>> @@ -289,6 +289,9 @@ typedef struct atmel_usart3 {
>>>   /* Constants for FI_DI_RATIO */
>>>   #define USART3_FI_DI_RATIO_DISABLE        0
>>>
>>> +/* chip revision mask */
>>> +#define AT91_CIDR_VERSION            0x1f
>>> +
>> NAK, this belongs to DBGU and not to USART. I think one of the specific
>> hardware.h would be a good place for that.
> 
> I will move it into at91sam9x5.h file.

can we use something like AT91_CIDR_VERSION_MASK or
ATMEL_CIDR_VERSION_MASK? I guess this is in every DBGU integrated and
could later be used to identify different atmel devices.

<snip>

>>
>>> +#define CONFIG_MACB_SEARCH_PHY
>>> +
>>> +#define CONFIG_SYS_LOAD_ADDR        0x22000000    /* load address */
>>> +
>>> +#define CONFIG_SYS_MEMTEST_START    CONFIG_SYS_SDRAM_BASE
>>> +#define CONFIG_SYS_MEMTEST_END        0x26e00000
>>> +
>>> +#ifdef CONFIG_SYS_USE_DATAFLASH
>>
>> dataflash is not implemented currently, is it?
> 
> Yes. At this stage, it doesn't implement yet.

Ok, so can you remove it here and add it when you implement dataflash
support?

> 
>>
>>> +
>>> +/* bootstrap + u-boot + env + linux in dataflash on CS0 */
>>> +#define CONFIG_ENV_IS_IN_SPI_FLASH
>>> +#define CONFIG_SYS_MONITOR_BASE    (0x10000000 + 0x8400)
>>> +#define CONFIG_ENV_OFFSET    0x5000
>>> +#define CONFIG_ENV_ADDR        (0x10000000 + CONFIG_ENV_OFFSET)
>>> +#define CONFIG_ENV_SIZE        0x3000
>>> +#define CONFIG_ENV_SECT_SIZE    0x1000
>>> +#define CONFIG_BOOTCOMMAND    "sf probe 0; " \
>>> +                "sf read 0x22000000 0x42000 0x300000; " \
>>> +                "bootm 0x22000000"
>>> +#else /* CONFIG_SYS_USE_NANDFLASH */
>>> +
>>> +/* bootstrap + u-boot + env + linux in nandflash */
>>> +#define CONFIG_ENV_IS_IN_NAND
>>> +#define CONFIG_ENV_OFFSET        0xc0000
>>> +#define CONFIG_ENV_OFFSET_REDUND    0x100000
>>> +#define CONFIG_ENV_SIZE        0x20000        /* 1 sector = 128 kB */
>>> +#define CONFIG_BOOTCOMMAND    "nand read.jffs2 " \
>>> +                "0x22000000 0x200000 0x300000; " \
>>> +                "bootm 0x22000000"
>>
>> Well, you read from jffs but work with ubifs later on? Is that ok?
>> BTW: I do not know 'nand read.jffs2', does this subcommand exist really?
> 
> Using the read with subfix .jffs2 it to skip the bad block. This
> partition is for Linux kernel.
> I will remove the .jffs2 to avoid confusing.

Well, it is ok with me to use read.jffs2 (if it works). I just do not
know about that subcommand and I can only find some references about
that in two other boards. I guess these boards are just forgotten while
removing the 'nand read.jffs2' command. Please check, if that command
works, if yes let it as is, if not rewrite.

Best regards

Andreas Bie?mann