On 14. 02. 20 16:20, Jens Rehsack wrote: > > >> Am 14.02.2020 um 15:43 schrieb Tom Rini <tr...@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 <tr...@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 <tr...@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 <mon...@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 <tr...@konsulko.com>: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 13, 2020 at 02:33:53PM +0100, Jens Rehsack wrote: >>>>>>>>>>>> >>>>>>>>>>>>> From: Jens Rehsack <s...@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 <s...@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
I am also sure that you will be fine. >>> 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. Just do that changes how they should look like. I also don't have some of these boards but we can ask others to test and ack. >> 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. Feel free to choose platforms which you know but we really need to have a use in mainline code to see usage. If this is useful we will convert Zynq platforms based on the same pattern later. Thanks, Michal