> Am 14.02.2020 um 10:36 schrieb Michal Simek <[email protected]>: > > On 13. 02. 20 18:48, Tom Rini wrote: >> On Thu, Feb 13, 2020 at 05:57:25PM +0100, Jens Rehsack wrote: >>> >>> >>>> Am 13.02.2020 um 16:01 schrieb Tom Rini <[email protected]>: >>>> >>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote: >>>> >>>>> From: Jens Rehsack <[email protected]> >>>>> >>>>> Introduce SUPPLIER analogous to VENDOR to allow (from customer >>>>> perspective) >>>>> a VENDOR using it's SUPPLIER's common/ code. >>>>> >>>>> This is reasonable, when a VENDOR (from customer perspective) builds >>>>> several machines sharing some features (e.g. some FPGA which has to be >>>>> initialized during u-boot) but wants to use common NXP or Samsung code >>>>> for the BSP instead of copying and create merge overhead. >>>>> >>>>> Signed-off-by: Jens Rehsack <[email protected]> >>>>> --- >>>>> Makefile | 4 +++- >>>>> arch/Kconfig | 12 ++++++++++++ >>>>> config.mk | 6 +++++- >>>>> 3 files changed, 20 insertions(+), 2 deletions(-) >>>> >>>> Can you provide a follow-up where this it clearer / easier to do >>>> something than today? Thanks! >>> >>> Given you buy - let's say some NXP SoC - LS20XX, LX21XX. The common >>> NXP code for the Management Complex is needed. I2C code either - this >>> covers board/freescale/common/... >>> >>> Given you build machines from there with different SoCs under a >>> new label - let's call it SuperLink, so you have >>> * board/freescale/common >>> * board/superlink/common >>> * board/superlink/legacy-tune <-- based on some PowerPC >>> * board/superlink/easy-tune <-- based on LS2088 >>> * board/superlink/heavy-tune <-- based on LX2160 >>> >>> All *-tune machines the customer buys from SuperLink have a >>> similar FPGA (there is a little bit more, but for the vision >>> it's probably better to stay small) and a similar external >>> PMIC/BMC. >>> >>> But SuperLink still uses code from board/freescale/common (their >>> supplier) and it's not reasonable to copy those. >>> >>> I rate all this not suitable for a commit message. How do >>> you suggest to proceed? >> >> Well, lets add in Michal as there are Zynq examples that could be >> cleaned up with what you're proposing. Similarly, Vanessa and Otavio >> might have thoughts here as they could rework some of the TechNexion >> boards. And Fabio for WaRP7 (and aside, should both warp/warp7 be moved >> from board/ to some sub-directory?). Thanks all! > > I think it will be the best to take any of your example and simply > create a series where this is applied to see if that code looks better > then before. Applying this without usage doesn't make sense.
I don't understand what you propose. Do you ask me to show internal
sources or the result of `find {...} -type f` or the content of our
Kconfig or defconfig?
I'll try to do as much as I can (I'm sure, showing internal code won't
be permitted).
> For zynq there are some boards like topic, bitmain, opalkelly which are
> staying in own folder but sourcing zynq board.c.
As said, freescale common code stays in board/freescale/common/ - and
our code is in board/"superlink"/...
Best regards
--
Jens Rehsack - [email protected]
signature.asc
Description: Message signed with OpenPGP
