[U-Boot] [PATCH v2] Add support for KMC KZM-ARM11-01 board
Atsuo Igarashi
atsuo_igarashi at tripeaks.co.jp
Wed Sep 10 09:14:42 CEST 2008
Dear Wolfgang Denk,
> Dear Atsuo Igarashi,
>
> In message <48C60E4F.6010704 at tripeaks.co.jp> you wrote:
>> Hi,
>>
>> I've fixed which Jean-Christophe pointed out.
>>
>> Regards,
>> Atsuo
>> ---
>> This patch adds support for KMC KZM-ARM11-01 board.
>>
>> Signed-off-by Atsuo Igarashi <atsuo_igarashi at tripeaks.co.jp>
>
> The you have the content of the message swapped. The "Hi, I've
> ..Regards, Atsuo" part belongs *below the '---' line, and the "This
> patch ... Signed-off-by:" part belongs *above* it.
>
> The text above the '---' line will become the commit message, the text
> below it is just comment.
Sorry, I'll do so next time.
>
> ...
>> +int board_init (void)
>> +{
>> + int i;
> ...
>> + /* RedBoot also has an empty loop with 100000 iterations here -
>> + * clock doesn't run yet */
>
> Incorrect multiline comment.
>
>> + for (i = 0; i < 100000; i++)
>> + ;
> ...
>> + /* clock still doesn't run */
>> + for (i = 0; i < 100000; i++)
>> + ;
>
> Be careful here, this might not do what you think it does. The
> compiler might optimize these loops away.
>
> Why are they needed in the first place?
>
Indeed. Since these are based on Freescale's ADS board,
I'm not sure what means these loops, but these not necessary for my board.
I'll remove these code of the CPLD initializing.
>> +/*
>> + * The MX31ADS board seems to have a hardware "peculiarity" confirmed under
>> + * U-Boot, RedBoot and Linux: the ethernet Rx signal is reaching the CS8900A
>> + * controller inverted. The controller is capable of detecting and correcting
>> + * this, but it needs 4 network packets for that. Which means, at startup, you
>> + * will not receive answers to the first 4 packest, unless there have been some
>> + * broadcasts on the network, or your board is on a hub. Reducing the ARP
>> + * timeout from default 5 seconds to 200ms we speed up the initial TFTP
>> + * transfer, should the user wish one, significantly.
>> + */
>> +#define CONFIG_ARP_TIMEOUT 200UL
>
>
> Is this really needed on your hardware, too? I doubt it.
>
Probably, this is not needed.
I'll remove this.
>> +#define CFG_HZ CONFIG_MX31_CLK32 /* use 32kHz clock as source */
>
> This is wrong. CFG_HZ must always be defined as 1000; it is a
> constant.
>
Okay, and it seems that I should fix something else too.
>> +/* Address and size of Redundant Environment Sector */
>> +#define CFG_ENV_OFFSET_REDUND (CFG_ENV_OFFSET + CFG_ENV_SIZE)
>> +#define CFG_ENV_SIZE_REDUND CFG_ENV_SIZE
>> +
>> +/* S29WS256N NOR flash has 4 32KiB small sectors at the beginning and at the end.
>> + * The rest of 32MiB is in 128KiB big sectors. U-Boot occupies the low 4 sectors,
>> + * if we put environment next to it, we will have to occupy 128KiB for it.
>> + * Putting it at the top of flash we use only 32KiB. */
>> +#define CFG_ENV_ADDR (CFG_MONITOR_BASE + CFG_ENV_SECT_SIZE)
>
> This is a very ugly set up, because you split the U-Boot related
> informatiomn, and you block both ends of your flash memory. Why don;t
> you locate the environment for example in the third and fourts
> sectors, i. e. use such a setup (called "embedded environment"):
>
> sector 1: 32 KiB - U-Boot code
> sector 2: 32 KiB - more U-Boot code
> sector 3: 32 KiB - environment, first copy
> sector 4: 32 KiB - environment, second (redundant) copy
> sector 5: 128 KiB - more U-Boot code
> ...
>
> ?
Indeed. I think so too.
I'll rework.
Regards,
Atsuo Igarashi
>
> Best regards,
>
> Wolfgang Denk
>
More information about the U-Boot
mailing list