From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 31 Oct 2011 18:42:35 +0100 Subject: [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support In-Reply-To: <4EA49D8E.2050704@mleia.com> References: <1318953340-30248-1-git-send-email-vz@mleia.com> <4EA200D9.9050206@aribaud.net> <4EA49D8E.2050704@mleia.com> Message-ID: <4EAEDE0B.7090201@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> --- >>> 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'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. 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. Amicalement, -- Albert.