[PATCH] {Makefile,config.mk,a/Kconfig}: introduce SUPPLIER

Fri Feb 14 16:20:56 CET 2020

> Am 14.02.2020 um 15:43 schrieb Tom Rini <trini at konsulko.com>:
> 
> On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote:
>> 
>> 
>>> Am 14.02.2020 um 15:28 schrieb Tom Rini <trini at konsulko.com>:
>>> 
>>> On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote:
>>>> 
>>>> 
>>>>> Am 14.02.2020 um 14:45 schrieb Tom Rini <trini at konsulko.com>:
>>>>> 
>>>>> On Fri, Feb 14, 2020 at 12:49:36PM +0100, Michal Simek wrote:
>>>>>> On 14. 02. 20 12:37, Jens Rehsack wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 14.02.2020 um 10:36 schrieb Michal Simek <monstr at monstr.eu>:
>>>>>>>> 
>>>>>>>> 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 <trini at konsulko.com>:
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> From: Jens Rehsack <sno at NetBSD.org>
>>>>>>>>>>>> 
>>>>>>>>>>>> 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 <sno at NetBSD.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>> 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"/...
>>>>>> 
>>>>>> I expect that you will find any example in the current code which can
>>>>>> use this feature. It means you can enable this feature and any current
>>>>>> configuration will really use it and will be regularly used/covered by
>>>>>> testing.
>>>>>> Adding feature which none will use in mainline should be IMHO nacked.
>>>>> 
>>>>> Yes.  All of the boards / people I added to the thread here have
>>>>> platforms that would be able to leverage this idea, so I was hoping they
>>>>> might have a perspective on if it would be clear than just:
>>>>> obj-y += ../../<vendor>/common/whatever.o
>>>>> like is done today.
>>>> 
>>>> So a PATCH-set with (likely non-working) examples will be fine or not?
>>> 
>>> No, but there are a number of existing configs that could be changed to
>>> use the framework you're suggesting.  So far it seems like the feedback
>>> has been that maybe this would be cleaner than just what I said above,
>>> but you need to convert some of them to use this, so we can see if it's
>>> really cleaner or not.
>> 
>> Yes, but I do not intend to refactor u-boot code. I'm not qualified to do that.
> 
> I'm sure you are.

Really - I'm not. I have very low experience in u-boot at all. Maybe it's getting
better over time, but for the very moment I disagree :P

>> Further: I'm in such a case not sure if it's the right tactic.
>> Since the SYS_SUPPLIER is introduced to have a 2nd vendor. When there're
>> BSP's from Vendors using common code from others and customers want to derive
>> from there, a 3rd level is relevant.
> 
> Yes, there's a number of platforms just like that in mainline today.
> Michal noted a few of them and I noted others.
> 
>> The entire idea is allowing machine builders to have an independent upper
>> level (vendor) from a lower level (supplier).
>> 
>> What you tell me would finally mean: vendor should be a list of paths instead
>> of a single path.
>> 
>> However - when you name a few places which could reasonably refactored, I'm
>> happy to give it a shot. Without guarantee :)
> 
> Well, the platforms Michal noted,

I can review zync boards and figure out how the topic, bitmain, opalkelly use
there some common stuff. But mind: I do not have any zync system and can't test
anything. So it will be completely dry what will come out.

> and the boards under board/technexion/
> that reference board/freescale/common/pfuze.o
> 
> If none of that really fits, perhaps you should just be doing:
> obj-y += ../../freescale/common/whatever.o
> in your superlink platforms.

The "superlink" is using a lot of configured stuff from freescale/common - and
different machines configure it differently (for reason), especially old PowerPC
and newer arm64 ones.

Best regards
--
Jens Rehsack - rehsack at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200214/b1556503/attachment.sig>