[U-Boot] [PATCH RFC 5/5] imx: mx6ul: Add initial board support for Engicam GEAM6UL

[Tom Rini <trini@konsulko.com>]

On Sun, Sep 04, 2016 at 11:47:06AM -0300, Fabio Estevam wrote:
> On Sun, Sep 4, 2016 at 10:32 AM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> 
> > Please do read the thread fully before commenting, I've mentioned the
> > state of hardware when I relied to Peng. And also this is an RFC patch
> > I'm looking for comments on function like changes whether the flow of
> > adding code to existing software is meaningful or not and not intended
> > to directly applying these onto ML.
> 
> I have already stated my opinion that you should put your board code
> into board/engicam.

Yes, this sounds right.

> > But I prefer to maintain the same on board/freescale/imx6ul. Becuase,
> > If the most of the code is common to all boards with specific SOC it's
> > better to have common code for reusability instead of adding different
> > board files with duplicate code. For example please see board/sunxi or
> > board/xilinx/zynq where microzed, zed or zynbo not directly
> > manufactured from xilinx but they maintained as common.
> 
> All the ifdefery inside board/sunxi/board.c is exactly what I would
> like to avoid here.

Now, in fairness to sunxi, that's more like what would happen if you
decided to support all of the imx6 and imx7 SoCs in a single board.c.

> mx6ul is a recent SoC and there is only mx6ul evk and pico mx6ul
> boards currently supported in U-Boot.
> 
> I don't think this can scale to support all upcoming boards into a
> single board/freescale/mx6ul/board.c.
> 
> Why is mx6ul special in this case compared to the other mx6 variants?
> 
> Will you be able to support all mx6q boards into
> board/freescale/mx6q/board.c as well?
> 
> I am sure this will be unmaintainable.

I suspect there's a certain amount of code that should be in
arch/arm/mach-imx/board.c like a __weak dram_init() and maybe some
${soc}.c files too for things that really aren't board specific but
rather SoC-required.  Of course I'm biased since this is how the TI
stuff evolved to.

But also, if the enigcam board is an example of "take the ref board, cut
it down a bit, ship" or even "take the ref board, tweak slightly", there
will still be some code duplication as they simply made the same board
decisions that NXP did in the reference platform.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160906/e0ba70ba/attachment.sig>