[U-Boot] [PATCH 1/2 V3] at91sam9261ek: make operational again

[Remy Bohmer]

Hi Reinhard,

>>> + * lockup during boot due to an overlap in the BSS segment. So, we
>>> choose a
>>> + * safe load adress to begin with, namely 0x20a00000
>>> + */
>>> +#define CONFIG_SYS_TEXT_BASE           0x20a00000
>
> I'd recommend setting this to the very beginning of SDRAM(0x20000000),
> note that initial SP and GD would be put into SRAM further down.

The SRAM is used by the LCD controller. So, we cannot use it for the SP and GD.

>>> +/* Define actual evaluation board type from used processor type */
>>> #ifdef CONFIG_AT91SAM9G10EK
>>> #define CONFIG_AT91SAM9G10      1       /* It's an Atmel AT91SAM9G10
>>> SoC*/
>>> #else
>>> #define CONFIG_AT91SAM9261      1       /* It's an Atmel AT91SAM9261
>>> SoC*/
>
> That looks to me the other way: its defining the processor type from the
> board type. If both boards are identical but for the processor, the
> processor
> should be defined in boards.cfg, like it is for 9260/9xe-ek.

This patch was originally meant for mainstream in the first place. It
was not meant to make it cleaner, just to make it compile and work
again.
The other patch was meant to make it cleaner according to your rework
and redesigns.

>>> #define CONFIG_NR_DRAM_BANKS            1
>>> -#define PHYS_SDRAM                     0x20000000
>>> -#define PHYS_SDRAM_SIZE                        0x04000000      /* 64
>>> megs */
>>> +#define CONFIG_SYS_SDRAM_BASE          0x20000000
>>> +#define CONFIG_SYS_SDRAM_SIZE          0x04000000 /* 64 megs */
>
> It is up to you, but (64 << 20) might look "nicer".

This is more a matter of taste I think. I will see what I do with it.

>>>
>>> +/* size in bytes reserved for initial data */
>>> +#define CONFIG_SYS_INIT_SP_ADDR                (CONFIG_SYS_SDRAM_BASE +
>>> 0x1000 \
>>> +                                       - GENERATED_GBL_DATA_SIZE)
>
> I've put that into SRAM, that facilitates future NOR flash boot variants
> where SDRAM
> would be initialized by low level it...

See LCD remark.

>>> AT91SAM9261_UHP_BASE */
>>> #ifdef CONFIG_AT91SAM9G10EK
>>> -#define CONFIG_SYS_USB_OHCI_SLOT_NAME          "at91sam9g10"
>>> +#define CONFIG_SYS_USB_OHCI_SLOT_NAME  "at91sam9g10"
>>> #else
>>> -#define CONFIG_SYS_USB_OHCI_SLOT_NAME          "at91sam9261"
>>> +#define CONFIG_SYS_USB_OHCI_SLOT_NAME  "at91sam9261"
>>> #endif
>
> Could we not use "ATMEL_CPU_NAME" here? Its capitalized,
> but I assume that would not matter?

Can be done.

>>
>> please merge move of at91sam9261 to boards.cfg from Patch 2/2 here, this
>> patch could IMHO still go into v2011.03; Patch 2/2 are changes for
>> u-boot-atmel/rework2011xxx branch ... Reinhard do you agree?
>
> In theory, yes, it could be considered a "bug fix". But whats the point of
> this double effort? Its easier when
> both patches are merged together and applied to top of rework.

Well, I would prefer if this patch goes to mainline as soon as
possible. I use this board to test the OHCI and USB-CDC stuff in the
u-boot-usb tree.
Your rework tree seems to be pending since november 2010, and I have
no clear view when that is going to mainline. So, since this board is
broken in mainline it is bothering my work as U-boot USB custodian.
So, do you have any objections if I would do the cleanups and
improvements in the 2/2 patch? Can you please push this patch upstream
as it is?

Kind regards,

Remy