[U-Boot] [PATCH 1/2] imx: mx6sxsabresd: drop SPL support

Jagan Teki jagannadh.teki at gmail.com
Thu May 11 10:29:43 UTC 2017


On Thu, May 11, 2017 at 3:41 PM, Stefano Babic <sbabic at denx.de> wrote:
> Hi everybody,
>
> On 11/05/2017 11:29, Peng Fan wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>>> Sent: Thursday, May 11, 2017 5:22 PM
>>> To: Peng Fan <peng.fan at nxp.com>
>>> Cc: Stefano Babic <sbabic at denx.de>; u-boot at lists.denx.de; Fabio Estevam
>>> <fabio.estevam at nxp.com>
>>> Subject: Re: [U-Boot] [PATCH 1/2] imx: mx6sxsabresd: drop SPL support
>>>
>>> On Thu, May 11, 2017 at 2:41 PM, Peng Fan <peng.fan at nxp.com> wrote:
>>>> We never use it, so drop the support.
>>>
>>> Do you have any memory constraints? just want to know why we drop the
>>> feature.
>>
>> SPL is not supported by NXP software releases.
>
> Well, I can understand this, but U-Boot is a community project..
>
>> And I do not want to maintain
>> the spl code, mainly ddr part. Internal, we have a ddr team to work out
>> ddr initialization script which could pass memory stress test and fine tuned.
>
> I have already written that I understand the position of a board
> maintainer and there are projects more suitable for SPL and other for
> u-boot.imx. Fine. I am not forcing people to do in a way or in another
> way, I am limiting to show the possibilities.
>
> Anyway, NXP boards are mostly evaluation boards and they are often taken
> as reference from other people to start a porting of their custom board.
> And then, developers will not completely rely on NXP releases - and they
> have to better understand when a solution is better as the other one. If
> just a solution is offered, they take that one because they cannot see
> an alternative one.
>
> If I have to say the whole truth, pushing hexadecimal tables to mainline

Yes, pushing hexadecimals to community project bit clumsy as per code
quality or other code related things are concern. And this is the main
reason of SPL changes on my recent patches.

> is not the best way to understand what is happening under the curtains.
> I am not reviewing the DCD tables, or I had to check each bit if this is
> correct or not. And for a board developer, who wants to port the own
> custom board, is much more clear to check number of row / columns for a
> RAM chip as done with SPL as with DCD - not everybody has a whole team
> bothering about RAM setup. I think that one goal of a community project
> as U-Boot should be also to show and make understandable what is done.
> Peng is saying the same (but with another goal): someone pushed to me a
> blob (=not easy to check), I will simply use it.
>
> I understand the point but I would be happier if we find a way (script,
> whatever, ...) that generates the SPL code from the DCD table to
> maintain the setup synchronized instead of dropping SPL.

Agree with Stefano, good to have a script generation here. Based on my
experience ddr_regs and gpr_regs value are similar with the processor
families like if the boards uses i.MX6q this part might be common and
etc, and ddr config parameters might have change.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.


More information about the U-Boot mailing list