> Am 14.02.2020 um 15:28 schrieb Tom Rini <[email protected]>: > > On Fri, Feb 14, 2020 at 03:21:44PM +0100, Jens Rehsack wrote: >> >> >>> Am 14.02.2020 um 14:45 schrieb Tom Rini <[email protected]>: >>> >>> 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 <[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"/... >>>> >>>> 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. 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. 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 :) Best regards -- Jens Rehsack - [email protected]
signature.asc
Description: Message signed with OpenPGP
