[Buildroot] [EXT] Re: [PATCH] boot/mv-ddr-marvell: support custom GIT settings
kostap at marvell.com
Wed Dec 26 10:59:22 UTC 2018
> -----Original Message-----
> From: Thomas Petazzoni <thomas.petazzoni at bootlin.com>
> Sent: Wednesday, December 26, 2018 12:32
> To: Kostya Porotchkin <kostap at marvell.com>
> Cc: Yann E. MORIN <yann.morin.1998 at free.fr>; buildroot at buildroot.org
> Subject: Re: [Buildroot] [EXT] Re: [PATCH] boot/mv-ddr-marvell: support
> custom GIT settings
> Hello Kostya,
> On Tue, 25 Dec 2018 09:09:26 +0000, Kostya Porotchkin wrote:
> > > As I see you're an @marvell.com, do you need that to use an internal
> > > repository during development? If so, then why can't you just use
> > > the OVERRIDE_SRCDIR mechanism instead?
> > [KP] It is more than just a local repository. I have to allow CI server to
> automatically build test and release images from the current internal GIT
> Sorry, but this is not a valid justification. With this justification, we would
> have to add version selection to *all* Buildroot packages.
> Indeed, one might want to do CI testing on any random user-space library or
> application. So if your use-case for wanting version selection in mv-ddr-
> marvell is CI testing, then we won't accept this patch.
[KP] Understand. We can keep this change private if you think others will not benefit from it.
> However, if people porting ATF/U-Boot to new Marvell-based platforms
> need to have their own custom version of mv-ddr-marvell, then having
> version selection can be accepted because it puts this package in the same
> situation as uboot, linux or atf, where we do offer version selection.
[KP] I am trying to find a reason for customer to use different mv-ddr releases.
It may happen if a customer wants to use older ATF base, for instance v1.3 instead of v1.5 or v2.0.
In such case the DDR API in latest mv-ddr release will not be compatible with it and the build will fail.
Another reason is a customer willing to use latest fixes in mv-ddr GIT prior to the official release drop.
For instance, the new V7 Espressobin boards were released with DDR4 chips, while our official SW only supported DDR3.
So the new board customers were forced to use outdated SW from vendor builds that supported such memory type.
> Best regards,
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
More information about the buildroot