[U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support

[Vladimir Zapolskiy]

Hi Albert,

On 31.10.2011 19:42, Albert ARIBAUD wrote:
> Hi Vladimir,
>
> Le 24/10/2011 01:04, Vladimir Zapolskiy a écrit :
>> Hi Albert,
>>
>> On 22.10.2011 02:31, Albert ARIBAUD wrote:
>>> Hi Vladimir,
>>>
>>> Le 18/10/2011 17:55, Vladimir Zapolskiy a écrit :
>>>> This change adds initial support for NXP LPC32x0 SoC series.
>>>>
>>>> Signed-off-by: Vladimir Zapolskiy<vz at mleia.com>
>>>> ---
>>>> Changes from v2 to v3:
>>>> * checkpatch.pl reports zero errors and warnings
>>>>
>>>> Changes from v1 to v2:
>>>> * BIT(n) and SBF(s, v) macro are not used anymore
>>>> * removed NS16550 and 14-clock UART definitions from uart.h
>>>> * added devices.c file, which contains standard UART preinitialization
>>>> routine
>>>> * added get_serial_clock() function, it returns actual frequency of
>>>> UART clock
>>>> * __udelay() realization is simplified, no need of interrupt handling
>>>
>>> As it stands, this is dead code until some board uses it; I imagine you
>>> have board waiting for this support. Can you submit the SoC and board
>>> code as a patch set? This way, it will be obvious for all that the SoC
>>> code in this patch has actual use.
>>
>> you're right, I have a board to make support for. However I presume that
>> U-boot maintainers won't be happy to include a board with
>> CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready
>> for publishing.
>
> CONFIG_ENV_IS_NOWHERE is the board( maintainer)'s business.
 >
> Ditto for the FLASH driver, if it is not required for use of the board
> (e.g., if U-Boot can fire up and does not need the FLASH to boot an OS,
> then a broken FLASH driver is an inconvenience, not a showstopper).

I've added CFI flash support to the board, however the environment is 
supposed to be stored in NAND flash, and that requires some more LPC32XX 
specific stuff to be developed for U-boot soon (basically that's NAND 
controller and DMA drivers).

>> I'd like to get an advice, if you think that weakly supported but
>> working U-boot on the board has chances to be included to arm-next I can
>> send the patchset right now for review, otherwise I'll spend some time
>> (one week approximately) to finish NAND driver.
>
> IMO, the acceptable state of a board is the board maintainer's affair,
> with a bare minimum that U-Boot must be able to play its role as a
> bootloader.
>
It's done in my understanding. Hopefully some more addons still should 
be implemented, and I'd like to concentrate on them being assured that 
the SoC and basic board support are pulled in.

> Anyway, since that is for next, not master, and since you think you can
> add the missing support far before the next merge window, I suggest you
> complete board support and add it to V4.
>

The initial board support was done and published a week ago, please 
check http://lists.denx.de/pipermail/u-boot/2011-October/106991.html

And that's my expression of willing to become a board maintainer, sorry 
it hasn't been included to the board changeset originally - 
http://lists.denx.de/pipermail/u-boot/2011-October/107069.html

I'd like to encourage you to check that the board specific compilation 
has zero warnings and checkpatch.pl output is clean.

-- 
With best wishes,
Vladimir