> Am 14.02.2020 um 15:43 schrieb Tom Rini <[email protected]>: > > On Fri, Feb 14, 2020 at 03:40:05PM +0100, Jens Rehsack wrote: >> >> >>> 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. > > 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 - [email protected]
signature.asc
Description: Message signed with OpenPGP
