All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Bießmann" <andreas.devel@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] arm : Atmel : add at91sam9x5ek board support
Date: Mon, 02 Jul 2012 11:47:55 +0200	[thread overview]
Message-ID: <4FF16E4B.4020601@gmail.com> (raw)
In-Reply-To: <4FF15D75.70003@gmail.com>

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

  reply	other threads:[~2012-07-02  9:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-02  3:35 [U-Boot] [PATCH v2] arm : Atmel : add at91sam9x5ek board support Bo Shen
2012-07-02  7:01 ` Andreas Bießmann
2012-07-02  8:36   ` Bo Shen
2012-07-02  9:47     ` Andreas Bießmann [this message]
2012-07-02  9:53       ` Nicolas Ferre
2012-07-02 10:02         ` Andreas Bießmann
2012-07-02 10:08           ` Nicolas Ferre
2012-07-02 10:23           ` Andreas Bießmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF16E4B.4020601@gmail.com \
    --to=andreas.devel@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.