Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Todd Weaver]

+Angus into the thread...

On Thu, 2018-06-21 at 02:07 +0100, André Przywara wrote:
> On 06/20/2018 06:16 PM, Paul Kocialkowski wrote:
> > Hi,
> > 
> > Le mercredi 20 juin 2018 à 17:12 +0100, Andre Przywara a écrit :
> > > On 20/06/18 16:24, Paul Kocialkowski wrote:
> > > > Regarding the DDR firmware: I would like to start a discussion
> > > > with NXP
> > > > and Synopsys about making the firmware free software/open
> > > > source.
> > > 
> > > Don't want to temper your enthusiasm, but I believe this has been
> > > tried
> > > before - in vain. Hence my proposal to work around this. This is
> > > a
> > > common problem for many platforms: DDR training or initialisation
> > > code
> > > is not documented and/or provided as a closed source blob.
> > > I very much appreciate your push for FOSS code, but I guess this
> > > is
> > > where reality kicks in.
> > 
> > I somewhat share your analysis here and I am well aware of the
> > general
> > issue (I remember not too long ago when nobody could say for sure
> > whether the Allwinner A64 platform would see free DRAM init code or
> > not)
> 
> I know, this is where I was coming from ;-) We tried to get the DRAM
> code from Allwinner, but this didn't really end well.
> I guess they will play ping-pong: Synopsis won't talk to you, since
> you
> are not their customer, and NXP will tell you that they can't share
> third party code, partly from Synopsis.
> 
> > but I still feel like trying the political way first is the most
> > reasonable way to go.
> > 
> > And I am definitely not going to give up so easily for now :)
> 
> OK, godspeed, and sorry for my pessimism!
> 
> > > There was and is quite some reverse engineering effort around
> > > this,
> > > though, and a lot of similarities have been found between the DDR
> > > controllers in different platforms, for instance between Rockchip
> > > and
> > > Allwinner. I believe it would be worthwhile to go over what we
> > > have in
> > > U-Boot and try to unify this. AFAIK many vendors use Synopsis IP,
> > > but
> > > don't necessarily say so. This might lead to some insight about
> > > the
> > > controllers used in i.MX as well.
> > 
> > Indeed, that is another not-so-painful way to go towards resolving
> > this
> > problem. And it also helps with the political way, since it seems
> > that
> > code covering these DRAM controllers' innards tends to come out
> > sooner
> > or later. So what's the point in Synopsys keeping it a secret?
> 
> Yeah, don't tell me!
> 
> > And even if the code can't be released as-is, I'm sure that
> > documentation that would allow writing a feature-equivalent
> > firmware
> > could be released without too much trouble involving lawyers.
> > 
> > Heck, it could even be released under NDA and a company could be
> > mandated to write such a clean firmware!
> 
> Please be careful when an NDAs is offered, that makes releasing the
> code
> under a FOSS license quite complicated. AFAIK most NDAs explicitly
> forbid this even. In the worst case you taint yourself for a long
> time
> from working with Open Source in this area.
> 
> > > > Would you be able to tell me who to contact about this
> > > > (probably a
> > > > manager on the NXP DDR team to begin with)? Feel free to answer
> > > > off-list 
> > > > if contact information cannot be shared publicly. 
> > > 
> > > Good luck with that, but don't be disappointed ...
> > 
> > To be honest, I would mostly feel disappointed for not trying!
> 
> Alright, keeping my fingers crossed!
> 
> Cheers,
> Andre.
> 
> > > > > > About that DDR PHY firmware: to what extent is it
> > > > > > necessary? It is
> > > > > > common that DDR link training is required for socketed DRAM
> > > > > > chips, but
> > > > > > properly-tuned static per-board configuration is usually
> > > > > > enough for
> > > > > > soldered DRAM chips. Is the i.MX8 and exception to that? If
> > > > > > not, would
> > > > > > it be possible to provide such a static configuration mode,
> > > > > > that does
> > > > > > not involved any firmware for link training?
> > > > > 
> > > > > The DDR PHY firmware is not per board. It is required.
> > > > > 
> > > > > There is a ddr tool developed by NXP, like what i.MX6/7 uses,
> > > > > it could generated
> > > > > the script like what this patch contains regarding the ddr
> > > > > part. But the DDR
> > > > > PHY firmware is a must, the DDR PHY firmware will be loaded
> > > > > to a place
> > > > > saying IMEM/DMEM inside DDR PHY.
> > > > 
> > > > Okay, so if I understand correctly, we there is already static
> > > > configuration. Do you know the role of the DDR PHY in details?
> > > > 
> > > > It is very unclear to me why the firmware is required. If you
> > > > do not
> > > > have the details, could you direct me to someone who knows such
> > > > details?
> > > > 
> > > > > > Perhaps the PHY link training code (with the firmware)
> > > > > > could be kept
> > > > > > around as a fallback, disabled by default. Also, I see lots
> > > > > > of
> > 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Wolfgang Denk]

Dear Andre,

In message <552c6e47-c700-829f-c03b-a8576f616...@arm.com> you wrote:
> 
> > Regarding the DDR firmware: I would like to start a discussion with NXP
> > and Synopsys about making the firmware free software/open source.
> 
> Don't want to temper your enthusiasm, but I believe this has been tried
> before - in vain. Hence my proposal to work around this. This is a
> common problem for many platforms: DDR training or initialisation code
> is not documented and/or provided as a closed source blob.
> I very much appreciate your push for FOSS code, but I guess this is
> where reality kicks in.

Reality can be changed. This has been done before.

Yes, some vendors think they have their crown jewels buried in their
RAM training or initialization code - of they realize it is so badly
written that they cannot allow other people to see it.

But we should always try to reduce such closed source parts to the
extend possible, and there have been a few cases where this
succeeded.  For example, it took quite some effort until Marvell
released the DDR3 init code under a License that allowed to
integrate it into U-Boot - today, all this is in mainline.

OK, with DDR4 the situation is still different.  But at least this
shows that it is always worth trying!

> There was and is quite some reverse engineering effort around this,
> though, and a lot of similarities have been found between the DDR
> controllers in different platforms, for instance between Rockchip and
> Allwinner. I believe it would be worthwhile to go over what we have in
> U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
> don't necessarily say so. This might lead to some insight about the
> controllers used in i.MX as well.

Of course this would be _much_ easier with at least minimal help
from the IP core / chip vendors...

> Good luck with that, but don't be disappointed ...

...and keep trying!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A Chairman was as necessary to a Board planet  as  the  zero  was  in
mathematics, but being a zero had big disadvantages...
 - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[André Przywara]

On 06/20/2018 06:16 PM, Paul Kocialkowski wrote:
> Hi,
> 
> Le mercredi 20 juin 2018 à 17:12 +0100, Andre Przywara a écrit :
>> On 20/06/18 16:24, Paul Kocialkowski wrote:
>>> Regarding the DDR firmware: I would like to start a discussion with NXP
>>> and Synopsys about making the firmware free software/open source.
>>
>> Don't want to temper your enthusiasm, but I believe this has been tried
>> before - in vain. Hence my proposal to work around this. This is a
>> common problem for many platforms: DDR training or initialisation code
>> is not documented and/or provided as a closed source blob.
>> I very much appreciate your push for FOSS code, but I guess this is
>> where reality kicks in.
> 
> I somewhat share your analysis here and I am well aware of the general
> issue (I remember not too long ago when nobody could say for sure
> whether the Allwinner A64 platform would see free DRAM init code or not)

I know, this is where I was coming from ;-) We tried to get the DRAM
code from Allwinner, but this didn't really end well.
I guess they will play ping-pong: Synopsis won't talk to you, since you
are not their customer, and NXP will tell you that they can't share
third party code, partly from Synopsis.

> but I still feel like trying the political way first is the most
> reasonable way to go.
> 
> And I am definitely not going to give up so easily for now :)

OK, godspeed, and sorry for my pessimism!

>> There was and is quite some reverse engineering effort around this,
>> though, and a lot of similarities have been found between the DDR
>> controllers in different platforms, for instance between Rockchip and
>> Allwinner. I believe it would be worthwhile to go over what we have in
>> U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
>> don't necessarily say so. This might lead to some insight about the
>> controllers used in i.MX as well.
> 
> Indeed, that is another not-so-painful way to go towards resolving this
> problem. And it also helps with the political way, since it seems that
> code covering these DRAM controllers' innards tends to come out sooner
> or later. So what's the point in Synopsys keeping it a secret?

Yeah, don't tell me!

> And even if the code can't be released as-is, I'm sure that
> documentation that would allow writing a feature-equivalent firmware
> could be released without too much trouble involving lawyers.
> 
> Heck, it could even be released under NDA and a company could be
> mandated to write such a clean firmware!

Please be careful when an NDAs is offered, that makes releasing the code
under a FOSS license quite complicated. AFAIK most NDAs explicitly
forbid this even. In the worst case you taint yourself for a long time
from working with Open Source in this area.

>>> Would you be able to tell me who to contact about this (probably a
>>> manager on the NXP DDR team to begin with)? Feel free to answer off-list 
>>> if contact information cannot be shared publicly. 
>>
>> Good luck with that, but don't be disappointed ...
> 
> To be honest, I would mostly feel disappointed for not trying!

Alright, keeping my fingers crossed!

Cheers,
Andre.

> About that DDR PHY firmware: to what extent is it necessary? It is
> common that DDR link training is required for socketed DRAM chips, but
> properly-tuned static per-board configuration is usually enough for
> soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> it be possible to provide such a static configuration mode, that does
> not involved any firmware for link training?

 The DDR PHY firmware is not per board. It is required.

 There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
 generated
 the script like what this patch contains regarding the ddr part. But the 
 DDR
 PHY firmware is a must, the DDR PHY firmware will be loaded to a place
 saying IMEM/DMEM inside DDR PHY.
>>>
>>> Okay, so if I understand correctly, we there is already static
>>> configuration. Do you know the role of the DDR PHY in details?
>>>
>>> It is very unclear to me why the firmware is required. If you do not
>>> have the details, could you direct me to someone who knows such details?
>>>
> Perhaps the PHY link training code (with the firmware) could be kept
> around as a fallback, disabled by default. Also, I see lots of
> undocumented registers in the process. Does it seem feasable to document
> these? This currently does not really like the source form of the
> software.

 There are lots lots of registers to configure, honestly, I also do not
 know the detailed meaning. The ddr code is from DDR team, hard
 for me to restructure. I suggest you use the DDR tool from NXP to
 generate the ddr code you need.
>>>
>>> Well, this is a very borderline situation, where we can consider that
>>> the register dumps are not really source code. I understand that you may
>>> not have the necessary 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi,

Le mercredi 20 juin 2018 à 17:12 +0100, Andre Przywara a écrit :
> On 20/06/18 16:24, Paul Kocialkowski wrote:
> > Regarding the DDR firmware: I would like to start a discussion with NXP
> > and Synopsys about making the firmware free software/open source.
> 
> Don't want to temper your enthusiasm, but I believe this has been tried
> before - in vain. Hence my proposal to work around this. This is a
> common problem for many platforms: DDR training or initialisation code
> is not documented and/or provided as a closed source blob.
> I very much appreciate your push for FOSS code, but I guess this is
> where reality kicks in.

I somewhat share your analysis here and I am well aware of the general
issue (I remember not too long ago when nobody could say for sure
whether the Allwinner A64 platform would see free DRAM init code or not)
but I still feel like trying the political way first is the most
reasonable way to go.

And I am definitely not going to give up so easily for now :)

> There was and is quite some reverse engineering effort around this,
> though, and a lot of similarities have been found between the DDR
> controllers in different platforms, for instance between Rockchip and
> Allwinner. I believe it would be worthwhile to go over what we have in
> U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
> don't necessarily say so. This might lead to some insight about the
> controllers used in i.MX as well.

Indeed, that is another not-so-painful way to go towards resolving this
problem. And it also helps with the political way, since it seems that
code covering these DRAM controllers' innards tends to come out sooner
or later. So what's the point in Synopsys keeping it a secret?

And even if the code can't be released as-is, I'm sure that
documentation that would allow writing a feature-equivalent firmware
could be released without too much trouble involving lawyers.

Heck, it could even be released under NDA and a company could be
mandated to write such a clean firmware!

> > Would you be able to tell me who to contact about this (probably a
> > manager on the NXP DDR team to begin with)? Feel free to answer off-list 
> > if contact information cannot be shared publicly. 
> 
> Good luck with that, but don't be disappointed ...

To be honest, I would mostly feel disappointed for not trying!

Cheers,

Paul

> > > > About that DDR PHY firmware: to what extent is it necessary? It is
> > > > common that DDR link training is required for socketed DRAM chips, but
> > > > properly-tuned static per-board configuration is usually enough for
> > > > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > > > it be possible to provide such a static configuration mode, that does
> > > > not involved any firmware for link training?
> > > 
> > > The DDR PHY firmware is not per board. It is required.
> > > 
> > > There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
> > > generated
> > > the script like what this patch contains regarding the ddr part. But the 
> > > DDR
> > > PHY firmware is a must, the DDR PHY firmware will be loaded to a place
> > > saying IMEM/DMEM inside DDR PHY.
> > 
> > Okay, so if I understand correctly, we there is already static
> > configuration. Do you know the role of the DDR PHY in details?
> > 
> > It is very unclear to me why the firmware is required. If you do not
> > have the details, could you direct me to someone who knows such details?
> > 
> > > > Perhaps the PHY link training code (with the firmware) could be kept
> > > > around as a fallback, disabled by default. Also, I see lots of
> > > > undocumented registers in the process. Does it seem feasable to document
> > > > these? This currently does not really like the source form of the
> > > > software.
> > > 
> > > There are lots lots of registers to configure, honestly, I also do not
> > > know the detailed meaning. The ddr code is from DDR team, hard
> > > for me to restructure. I suggest you use the DDR tool from NXP to
> > > generate the ddr code you need.
> > 
> > Well, this is a very borderline situation, where we can consider that
> > the register dumps are not really source code. I understand that you may
> > not have the necessary information here. Do you know who to contact to
> > solve this problem?
> > 
> > > > Having a firmware in the boot process is a fatal flaw when it comes to
> > > > software freedom, as it prevents having a fully free boot chain. Since
> > > > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > > > for this precise reason, this is a serious (if not fatal) drawback.
> > > 
> > > The DDR PHY firmware runs inside DDR PHY, it is only DDR TYPE specific,
> > > such as DDR4 and LPDDR4 use different DDR PHY firmware.
> > 
> > I see, that makes sense.
> > 
> > > If different boards use LPDDR4, they could use same firmware.
> > > 
> > > > 
> > > > Moreover, it is really not convenient to have a non-free firmware that

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Andre Przywara]

Hi,

On 20/06/18 16:24, Paul Kocialkowski wrote:
> Hi and thanks for your anwers!
> 
> On Wed, 2018-06-20 at 11:56 +, Peng Fan wrote:
>> Hi Paul
>>
>>> -Original Message-
>>> From: Paul Kocialkowski [mailto:cont...@paulk.fr]
>>> Sent: 2018年6月20日 16:58
>>> To: Peng Fan ; sba...@denx.de; Fabio Estevam
>>> 
>>> Cc: u-boot@lists.denx.de; andre.przyw...@arm.com; Todd Weaver
>>> ; Nicole Faerber 
>>> Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
>>>
>>> Hi there,
>>>
>>> On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
>>>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>>>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>>>> DRAM.
>>>
>>> First off, I'd like to express my gratitude for this port: the i.MX8
>>> looks like a great platform and it's really nice to see support for it
>>> land in U-Boot!
>>>
>>> Regarding the integration of i.MX8 with upstream software in general:
>>> are there plans to upstream the ARM Trusted Firmware port for i.MX8?
>>
>> There are i.MX8 i.MX8X i.MX8M product lines for now. This patchset
>> is upstream i.MX8MQ in i.MX8M family.
>>
>> The i.MX8QM in i.MX8 and i.MX8QXP in i.MX8X has been upstreamed to
>> ATF recently. The i.MX8MQ support will be soon sent to ATF, I think.
> 
> Okay, thanks for the clarification, this is good to know :)

Yeah, this naming is really fun ...

>>> It would be great to have both U-Boot and ATF upstream support to
>>> achieve a boot chain with (mostly-)free and upstream software.
>>>
>>> On that note, are there proprietary components involved in the boot
>>> process, other than the already-identified DDR training firmware for the
>>> DDR PHY?
>>
>> The DDR firmware is not opensource, also there is HDMI firmware.
>> U-Boot will load DDR PHY firmware and initialize DDR controller.
> 
> Oh, I didn't know about the HDMI firmware.
> 
> Regarding the DDR firmware: I would like to start a discussion with NXP
> and Synopsys about making the firmware free software/open source.

Don't want to temper your enthusiasm, but I believe this has been tried
before - in vain. Hence my proposal to work around this. This is a
common problem for many platforms: DDR training or initialisation code
is not documented and/or provided as a closed source blob.
I very much appreciate your push for FOSS code, but I guess this is
where reality kicks in.

There was and is quite some reverse engineering effort around this,
though, and a lot of similarities have been found between the DDR
controllers in different platforms, for instance between Rockchip and
Allwinner. I believe it would be worthwhile to go over what we have in
U-Boot and try to unify this. AFAIK many vendors use Synopsis IP, but
don't necessarily say so. This might lead to some insight about the
controllers used in i.MX as well.

> Would you be able to tell me who to contact about this (probably a
> manager on the NXP DDR team to begin with)? Feel free to answer off-list 
> if contact information cannot be shared publicly. 

Good luck with that, but don't be disappointed ...

Cheers,
Andre.

>>> About that DDR PHY firmware: to what extent is it necessary? It is
>>> common that DDR link training is required for socketed DRAM chips, but
>>> properly-tuned static per-board configuration is usually enough for
>>> soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
>>> it be possible to provide such a static configuration mode, that does
>>> not involved any firmware for link training?
>>
>> The DDR PHY firmware is not per board. It is required.
>>
>> There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
>> generated
>> the script like what this patch contains regarding the ddr part. But the DDR
>> PHY firmware is a must, the DDR PHY firmware will be loaded to a place
>> saying IMEM/DMEM inside DDR PHY.
> 
> Okay, so if I understand correctly, we there is already static
> configuration. Do you know the role of the DDR PHY in details?
> 
> It is very unclear to me why the firmware is required. If you do not
> have the details, could you direct me to someone who knows such details?
> 
>>> Perhaps the PHY link training code (with the firmware) could be kept
>>> around as a fallback, disabled by default. Also, I see lots of
>>> undocumented registers in the process. Does it seem feasable to document
>>> these? This currently does not really like the source form of the
>>> software.
>>
>

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi and thanks for your anwers!

On Wed, 2018-06-20 at 11:56 +, Peng Fan wrote:
> Hi Paul
> 
> > -Original Message-
> > From: Paul Kocialkowski [mailto:cont...@paulk.fr]
> > Sent: 2018年6月20日 16:58
> > To: Peng Fan ; sba...@denx.de; Fabio Estevam
> > 
> > Cc: u-boot@lists.denx.de; andre.przyw...@arm.com; Todd Weaver
> > ; Nicole Faerber 
> > Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
> > 
> > Hi there,
> > 
> > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > DRAM.
> > 
> > First off, I'd like to express my gratitude for this port: the i.MX8
> > looks like a great platform and it's really nice to see support for it
> > land in U-Boot!
> > 
> > Regarding the integration of i.MX8 with upstream software in general:
> > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> 
> There are i.MX8 i.MX8X i.MX8M product lines for now. This patchset
> is upstream i.MX8MQ in i.MX8M family.
> 
> The i.MX8QM in i.MX8 and i.MX8QXP in i.MX8X has been upstreamed to
> ATF recently. The i.MX8MQ support will be soon sent to ATF, I think.

Okay, thanks for the clarification, this is good to know :)

> > It would be great to have both U-Boot and ATF upstream support to
> > achieve a boot chain with (mostly-)free and upstream software.
> > 
> > On that note, are there proprietary components involved in the boot
> > process, other than the already-identified DDR training firmware for the
> > DDR PHY?
> 
> The DDR firmware is not opensource, also there is HDMI firmware.
> U-Boot will load DDR PHY firmware and initialize DDR controller.

Oh, I didn't know about the HDMI firmware.

Regarding the DDR firmware: I would like to start a discussion with NXP
and Synopsys about making the firmware free software/open source.

Would you be able to tell me who to contact about this (probably a
manager on the NXP DDR team to begin with)? Feel free to answer off-list 
if contact information cannot be shared publicly. 

> > About that DDR PHY firmware: to what extent is it necessary? It is
> > common that DDR link training is required for socketed DRAM chips, but
> > properly-tuned static per-board configuration is usually enough for
> > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > it be possible to provide such a static configuration mode, that does
> > not involved any firmware for link training?
> 
> The DDR PHY firmware is not per board. It is required.
> 
> There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could 
> generated
> the script like what this patch contains regarding the ddr part. But the DDR
> PHY firmware is a must, the DDR PHY firmware will be loaded to a place
> saying IMEM/DMEM inside DDR PHY.

Okay, so if I understand correctly, we there is already static
configuration. Do you know the role of the DDR PHY in details?

It is very unclear to me why the firmware is required. If you do not
have the details, could you direct me to someone who knows such details?

> > Perhaps the PHY link training code (with the firmware) could be kept
> > around as a fallback, disabled by default. Also, I see lots of
> > undocumented registers in the process. Does it seem feasable to document
> > these? This currently does not really like the source form of the
> > software.
> 
> There are lots lots of registers to configure, honestly, I also do not
> know the detailed meaning. The ddr code is from DDR team, hard
> for me to restructure. I suggest you use the DDR tool from NXP to
> generate the ddr code you need.

Well, this is a very borderline situation, where we can consider that
the register dumps are not really source code. I understand that you may
not have the necessary information here. Do you know who to contact to
solve this problem?

> > Having a firmware in the boot process is a fatal flaw when it comes to
> > software freedom, as it prevents having a fully free boot chain. Since
> > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > for this precise reason, this is a serious (if not fatal) drawback.
> 
> The DDR PHY firmware runs inside DDR PHY, it is only DDR TYPE specific,
> such as DDR4 and LPDDR4 use different DDR PHY firmware.

I see, that makes sense.

> If different boards use LPDDR4, they could use same firmware.
> 
> > 
> > Moreover, it is really not convenient to have a non-free firmware that
> > must be carried around with U-Boot and prevents user from just cloning
> > u-boot, build

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

On Wed, 2018-06-20 at 13:54 +0200, Paul Kocialkowski wrote:
> Hi,
> 
> On Wed, 2018-06-20 at 12:37 +0100, Andre Przywara wrote:
> > (resending trimmed version to pass the U-Boot size limit filter ...)
> > 
> > Hi,
> > 
> > On 20/06/18 09:57, Paul Kocialkowski wrote:
> > > Hi there,
> > > 
> > > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > > DRAM.
> > > 
> > > First off, I'd like to express my gratitude for this port: the i.MX8
> > > looks like a great platform and it's really nice to see support for it
> > > land in U-Boot!
> > > 
> > > Regarding the integration of i.MX8 with upstream software in general:
> > > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> > > It would be great to have both U-Boot and ATF upstream support to
> > > achieve a boot chain with (mostly-)free and upstream software.
> > 
> > The support for i.MX8QX and i.MX8QM has been merged into the official
> > ATF repo yesterday:
> > https://github.com/ARM-software/arm-trusted-firmware/pull/1410
> > 
> > I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
> > should answer your question.
> 
> Great to hear and great work! I must admit, I did not even check ATF
> sources when writing the email from this morning, as it seemed too early
> anyway.
> 
> I'm definitely glad I was wrong :)
> 
> > > On that note, are there proprietary components involved in the boot
> > > process, other than the already-identified DDR training firmware for the
> > > DDR PHY?
> > > 
> > > About that DDR PHY firmware: to what extent is it necessary? It is
> > > common that DDR link training is required for socketed DRAM chips, but
> > > properly-tuned static per-board configuration is usually enough for
> > > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > > it be possible to provide such a static configuration mode, that does
> > > not involved any firmware for link training?
> > 
> > I agree on not wanting a blob for that, although that depends a bit on
> > what it does: If it's an not-signed binary, that just does the training
> > and then goes out of the way, and shipping the binary is reasonably
> > licensed, then it might be beneficial to have it, at least for now.
> 
> Well, that covers some use cases, but definitely does not help with
> software freedom issues, that can only be solved by either avoiding or
> liberating that blob. Even following the RYF approach that Purism is
> considering[0] (moving DDR calibration to a coprocessor) does not help
> at all with freedom issues and is merely an "exception" that the FSF's
> RYF certification allows.
> 
> I did not mention it, but perhaps NXP is in a positon to ask Designware
> to free that blob altogether (which would definitely solve the issue at
> hand here)?

I meant Synopsys (the company), not Designware (the line of products)
here.

> > AFAIK actual DRAM training for a wide range of chips is not trivial, so
> > there is probably some value in that blob.
> > For specific boards with soldered chips: can't we dump the results of
> > the training and use that for a static configuration? It is my
> > understanding that the DRAM controller parameters depend on actual
> > voltage and also temperature, but we might get some good enough values
> > for a reasonable range of both? This would make this blob optional then,
> > and people could decide for their own.
> 
> This is also my understanding and I would totally be satisfied with this
> approach, as I mentioned earlier.
> 
> Thanks for the reply!
> 
> Paul
> 
> [0]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/
> 
> > Cheers,
> > Andre.
> > 
> > > Perhaps the PHY link training code (with the firmware) could be kept
> > > around as a fallback, disabled by default. Also, I see lots of
> > > undocumented registers in the process. Does it seem feasable to document
> > > these? This currently does not really like the source form of the
> > > software.
> > > 
> > > Having a firmware in the boot process is a fatal flaw when it comes to
> > > software freedom, as it prevents having a fully free boot chain. Since
> > > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > > for this precise reason, this is a serious (if not fatal) drawback.
> > > 
> > > Moreover, it is really not convenient to have a non-free firmware that
> > > must be carried around with U-Boot and prevents user from just cloning
> > > u-boot, building and running (by adding an extra step that complicates
> > > the process and makes it different from other platforms that do not
> > > require such a blob).
> > > 
> > > Thanks in advance for your time and consideration of these questions!
> > > 
> > > Cheers,
> > > 
> > > Paul
> > > 
> > > > The boot log with Arm trusted firmware console enabled:
> > > > "
> > > > U-Boot SPL 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Hi Paul

> -Original Message-
> From: Paul Kocialkowski [mailto:cont...@paulk.fr]
> Sent: 2018年6月20日 16:58
> To: Peng Fan ; sba...@denx.de; Fabio Estevam
> 
> Cc: u-boot@lists.denx.de; andre.przyw...@arm.com; Todd Weaver
> ; Nicole Faerber 
> Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
> 
> Hi there,
> 
> On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > DRAM.
> 
> First off, I'd like to express my gratitude for this port: the i.MX8
> looks like a great platform and it's really nice to see support for it
> land in U-Boot!
> 
> Regarding the integration of i.MX8 with upstream software in general:
> are there plans to upstream the ARM Trusted Firmware port for i.MX8?

There are i.MX8 i.MX8X i.MX8M product lines for now. This patchset
is upstream i.MX8MQ in i.MX8M family.

The i.MX8QM in i.MX8 and i.MX8QXP in i.MX8X has been upstreamed to
ATF recently. The i.MX8MQ support will be soon sent to ATF, I think.

> It would be great to have both U-Boot and ATF upstream support to
> achieve a boot chain with (mostly-)free and upstream software.
> 
> On that note, are there proprietary components involved in the boot
> process, other than the already-identified DDR training firmware for the
> DDR PHY?

The DDR firmware is not opensource, also there is HDMI firmware.
U-Boot will load DDR PHY firmware and initialize DDR controller.

> 
> About that DDR PHY firmware: to what extent is it necessary? It is
> common that DDR link training is required for socketed DRAM chips, but
> properly-tuned static per-board configuration is usually enough for
> soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> it be possible to provide such a static configuration mode, that does
> not involved any firmware for link training?

The DDR PHY firmware is not per board. It is required.

There is a ddr tool developed by NXP, like what i.MX6/7 uses, it could generated
the script like what this patch contains regarding the ddr part. But the DDR
PHY firmware is a must, the DDR PHY firmware will be loaded to a place
saying IMEM/DMEM inside DDR PHY.

> 
> Perhaps the PHY link training code (with the firmware) could be kept
> around as a fallback, disabled by default. Also, I see lots of
> undocumented registers in the process. Does it seem feasable to document
> these? This currently does not really like the source form of the
> software.

There are lots lots of registers to configure, honestly, I also do not
know the detailed meaning. The ddr code is from DDR team, hard
for me to restructure. I suggest you use the DDR tool from NXP to
generate the ddr code you need.

> 
> Having a firmware in the boot process is a fatal flaw when it comes to
> software freedom, as it prevents having a fully free boot chain. Since
> some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> for this precise reason, this is a serious (if not fatal) drawback.

The DDR PHY firmware runs inside DDR PHY, it is only DDR TYPE specific,
such as DDR4 and LPDDR4 use different DDR PHY firmware.

If different boards use LPDDR4, they could use same firmware.

> 
> Moreover, it is really not convenient to have a non-free firmware that
> must be carried around with U-Boot and prevents user from just cloning
> u-boot, building and running (by adding an extra step that complicates
> the process and makes it different from other platforms that do not
> require such a blob).

imx-mkimage, might be good to added into U-Boot as Stefano suggests.
Then it will be easy a lot. But the firmware could not be avoided.
> 
> Thanks in advance for your time and consideration of these questions!

Things become complicated, good documentation is required.

Shame on me that the ddr code still be held there.

Regards,
Peng.

> 
> Cheers,
> 
> Paul
> 

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi,

On Wed, 2018-06-20 at 12:37 +0100, Andre Przywara wrote:
> (resending trimmed version to pass the U-Boot size limit filter ...)
> 
> Hi,
> 
> On 20/06/18 09:57, Paul Kocialkowski wrote:
> > Hi there,
> > 
> > On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> > > Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> > > firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> > > DRAM.
> > 
> > First off, I'd like to express my gratitude for this port: the i.MX8
> > looks like a great platform and it's really nice to see support for it
> > land in U-Boot!
> > 
> > Regarding the integration of i.MX8 with upstream software in general:
> > are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> > It would be great to have both U-Boot and ATF upstream support to
> > achieve a boot chain with (mostly-)free and upstream software.
> 
> The support for i.MX8QX and i.MX8QM has been merged into the official
> ATF repo yesterday:
> https://github.com/ARM-software/arm-trusted-firmware/pull/1410
> 
> I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
> should answer your question.

Great to hear and great work! I must admit, I did not even check ATF
sources when writing the email from this morning, as it seemed too early
anyway.

I'm definitely glad I was wrong :)

> > On that note, are there proprietary components involved in the boot
> > process, other than the already-identified DDR training firmware for the
> > DDR PHY?
> > 
> > About that DDR PHY firmware: to what extent is it necessary? It is
> > common that DDR link training is required for socketed DRAM chips, but
> > properly-tuned static per-board configuration is usually enough for
> > soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> > it be possible to provide such a static configuration mode, that does
> > not involved any firmware for link training?
> 
> I agree on not wanting a blob for that, although that depends a bit on
> what it does: If it's an not-signed binary, that just does the training
> and then goes out of the way, and shipping the binary is reasonably
> licensed, then it might be beneficial to have it, at least for now.

Well, that covers some use cases, but definitely does not help with
software freedom issues, that can only be solved by either avoiding or
liberating that blob. Even following the RYF approach that Purism is
considering[0] (moving DDR calibration to a coprocessor) does not help
at all with freedom issues and is merely an "exception" that the FSF's
RYF certification allows.

I did not mention it, but perhaps NXP is in a positon to ask Designware
to free that blob altogether (which would definitely solve the issue at
hand here)?

> AFAIK actual DRAM training for a wide range of chips is not trivial, so
> there is probably some value in that blob.
> For specific boards with soldered chips: can't we dump the results of
> the training and use that for a static configuration? It is my
> understanding that the DRAM controller parameters depend on actual
> voltage and also temperature, but we might get some good enough values
> for a reasonable range of both? This would make this blob optional then,
> and people could decide for their own.

This is also my understanding and I would totally be satisfied with this
approach, as I mentioned earlier.

Thanks for the reply!

Paul

[0]: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/

> Cheers,
> Andre.
> 
> > Perhaps the PHY link training code (with the firmware) could be kept
> > around as a fallback, disabled by default. Also, I see lots of
> > undocumented registers in the process. Does it seem feasable to document
> > these? This currently does not really like the source form of the
> > software.
> > 
> > Having a firmware in the boot process is a fatal flaw when it comes to
> > software freedom, as it prevents having a fully free boot chain. Since
> > some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> > for this precise reason, this is a serious (if not fatal) drawback.
> > 
> > Moreover, it is really not convenient to have a non-free firmware that
> > must be carried around with U-Boot and prevents user from just cloning
> > u-boot, building and running (by adding an extra step that complicates
> > the process and makes it different from other platforms that do not
> > require such a blob).
> > 
> > Thanks in advance for your time and consideration of these questions!
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > The boot log with Arm trusted firmware console enabled:
> > > "
> > > U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> > > PMIC:  PFUZE100 ID=0x10
> > > Normal Boot
> > > Trying to boot from MMC2
> > > NOTICE:  Configureing TZASC380
> > > NOTICE:  BL31: 
> > > v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> > > NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
> > > NOTICE:  sip svc init
> > > 
> > > U-Boot 

[U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Andre Przywara]

(resending trimmed version to pass the U-Boot size limit filter ...)

Hi,

On 20/06/18 09:57, Paul Kocialkowski wrote:
> Hi there,
> 
> On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>> DRAM.
> 
> First off, I'd like to express my gratitude for this port: the i.MX8
> looks like a great platform and it's really nice to see support for it
> land in U-Boot!
> 
> Regarding the integration of i.MX8 with upstream software in general:
> are there plans to upstream the ARM Trusted Firmware port for i.MX8?
> It would be great to have both U-Boot and ATF upstream support to
> achieve a boot chain with (mostly-)free and upstream software.

The support for i.MX8QX and i.MX8QM has been merged into the official
ATF repo yesterday:
https://github.com/ARM-software/arm-trusted-firmware/pull/1410

I am bit lost in the naming here (i.MX8QM vs i.MX8MQ), but I think that
should answer your question.

> On that note, are there proprietary components involved in the boot
> process, other than the already-identified DDR training firmware for the
> DDR PHY?
> 
> About that DDR PHY firmware: to what extent is it necessary? It is
> common that DDR link training is required for socketed DRAM chips, but
> properly-tuned static per-board configuration is usually enough for
> soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
> it be possible to provide such a static configuration mode, that does
> not involved any firmware for link training?

I agree on not wanting a blob for that, although that depends a bit on
what it does: If it's an not-signed binary, that just does the training
and then goes out of the way, and shipping the binary is reasonably
licensed, then it might be beneficial to have it, at least for now.
AFAIK actual DRAM training for a wide range of chips is not trivial, so
there is probably some value in that blob.
For specific boards with soldered chips: can't we dump the results of
the training and use that for a static configuration? It is my
understanding that the DRAM controller parameters depend on actual
voltage and also temperature, but we might get some good enough values
for a reasonable range of both? This would make this blob optional then,
and people could decide for their own.

Cheers,
Andre.

> Perhaps the PHY link training code (with the firmware) could be kept
> around as a fallback, disabled by default. Also, I see lots of
> undocumented registers in the process. Does it seem feasable to document
> these? This currently does not really like the source form of the
> software.
> 
> Having a firmware in the boot process is a fatal flaw when it comes to
> software freedom, as it prevents having a fully free boot chain. Since
> some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
> for this precise reason, this is a serious (if not fatal) drawback.
> 
> Moreover, it is really not convenient to have a non-free firmware that
> must be carried around with U-Boot and prevents user from just cloning
> u-boot, building and running (by adding an extra step that complicates
> the process and makes it different from other platforms that do not
> require such a blob).
> 
> Thanks in advance for your time and consideration of these questions!
> 
> Cheers,
> 
> Paul
> 
>> The boot log with Arm trusted firmware console enabled:
>> "
>> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
>> PMIC:  PFUZE100 ID=0x10
>> Normal Boot
>> Trying to boot from MMC2
>> NOTICE:  Configureing TZASC380
>> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
>> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
>> NOTICE:  sip svc init
>>
>> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
>>
>> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
>> Reset cause: POR
>> Model: Freescale i.MX8MQ EVK
>> DRAM:  3 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> Using default environment
>>
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> u-boot=>
>> "
>>
>> Signed-off-by: Peng Fan 
>> Cc: Fabio Estevam 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/dts/Makefile|2 +
>>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>>  board/freescale/mx8mq_evk/Kconfig|   12 +
>>  board/freescale/mx8mq_evk/Makefile   |   12 +
>>  board/freescale/mx8mq_evk/README |   47 +
>>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
>> ++
>>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>>  board/freescale/mx8mq_evk/spl.c  |  230 +
>>  

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Paul Kocialkowski]

Hi there,

On Wed, 2018-01-10 at 13:20 +0800, Peng Fan wrote:
> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> DRAM.

First off, I'd like to express my gratitude for this port: the i.MX8
looks like a great platform and it's really nice to see support for it
land in U-Boot!

Regarding the integration of i.MX8 with upstream software in general:
are there plans to upstream the ARM Trusted Firmware port for i.MX8?
It would be great to have both U-Boot and ATF upstream support to
achieve a boot chain with (mostly-)free and upstream software.

On that note, are there proprietary components involved in the boot
process, other than the already-identified DDR training firmware for the
DDR PHY?

About that DDR PHY firmware: to what extent is it necessary? It is
common that DDR link training is required for socketed DRAM chips, but
properly-tuned static per-board configuration is usually enough for
soldered DRAM chips. Is the i.MX8 and exception to that? If not, would
it be possible to provide such a static configuration mode, that does
not involved any firmware for link training?

Perhaps the PHY link training code (with the firmware) could be kept
around as a fallback, disabled by default. Also, I see lots of
undocumented registers in the process. Does it seem feasable to document
these? This currently does not really like the source form of the
software.

Having a firmware in the boot process is a fatal flaw when it comes to
software freedom, as it prevents having a fully free boot chain. Since
some projects (e.g. the Purism Librem 5) are aiming at using the i.MX8
for this precise reason, this is a serious (if not fatal) drawback.

Moreover, it is really not convenient to have a non-free firmware that
must be carried around with U-Boot and prevents user from just cloning
u-boot, building and running (by adding an extra step that complicates
the process and makes it different from other platforms that do not
require such a blob).

Thanks in advance for your time and consideration of these questions!

Cheers,

Paul

> The boot log with Arm trusted firmware console enabled:
> "
> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> PMIC:  PFUZE100 ID=0x10
> Normal Boot
> Trying to boot from MMC2
> NOTICE:  Configureing TZASC380
> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
> NOTICE:  sip svc init
> 
> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
> 
> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
> Reset cause: POR
> Model: Freescale i.MX8MQ EVK
> DRAM:  3 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> u-boot=>
> "
> 
> Signed-off-by: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile|2 +
>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>  board/freescale/mx8mq_evk/Kconfig|   12 +
>  board/freescale/mx8mq_evk/Makefile   |   12 +
>  board/freescale/mx8mq_evk/README |   47 +
>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
> ++
>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>  board/freescale/mx8mq_evk/spl.c  |  230 +
>  configs/mx8mq_evk_defconfig  |   27 +
>  include/configs/mx8mq_evk.h  |  269 ++
>  14 files changed, 2819 insertions(+)
>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>  create mode 100644 board/freescale/mx8mq_evk/README
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>  create mode 100644 configs/mx8mq_evk_defconfig
>  create mode 100644 include/configs/mx8mq_evk.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a895c70284..299107977f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>  
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  
> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
> +
>  dtb-$(CONFIG_RCAR_GEN3) += \
>   r8a7795-h3ulcb.dtb \
>   r8a7795-salvator-x.dtb \
> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts b/arch/arm/dts/fsl-imx8mq-evk.dts
> new file 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Hi Fabio

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2018年3月21日 3:47
> To: Peng Fan <van.free...@gmail.com>
> Cc: Peng Fan <peng@nxp.com>; Fabio Estevam <fabio.este...@nxp.com>;
> U-Boot-Denx <u-boot@lists.denx.de>
> Subject: Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support
> 
> Hi Peng,
> 
> On Fri, Feb 23, 2018 at 3:02 AM, Peng Fan <van.free...@gmail.com> wrote:
> 
> >
> > I was a bit busy on other things. Regarding the board support, I still
> > do not have a good idea about the DDR things. I am thinking moving the
> > ddr code out into a dedicated bin file and pad to the end of SPL.
> >
> > What do you think?
> 
> Or maybe move the files below to a common mx8m location?
> 
>  board/freescale/mx8mq_evk/ddr/ddr_init.c
>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>  board/freescale/mx8mq_evk/ddr/helper.c
The thing is that the magic code there and need each board has a copy.
I am rewriting code according to RPA and ddrtool, but progress is slow.
I am not ddr expert, the best choice to me is to move the code out
Uboot, but there is no good place to put the code.
> 
> Still hoping we can get mx8mevk support for v2018.05 :-)
I try.

Thanks,
Peng.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Peng,

On Fri, Feb 23, 2018 at 3:02 AM, Peng Fan  wrote:

>
> I was a bit busy on other things. Regarding the board support, I still
> do not have a good idea about the DDR things. I am thinking moving
> the ddr code out into a dedicated bin file and pad to the end of SPL.
>
> What do you think?

Or maybe move the files below to a common mx8m location?

 board/freescale/mx8mq_evk/ddr/ddr_init.c
 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
 board/freescale/mx8mq_evk/ddr/helper.c

Still hoping we can get mx8mevk support for v2018.05 :-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Peng,

On Fri, Feb 23, 2018 at 3:02 AM, Peng Fan  wrote:

>>Do you plan to post a new version for the patch that adds the mx8mq evk 
>>support?
>
> I was a bit busy on other things. Regarding the board support, I still
> do not have a good idea about the DDR things. I am thinking moving
> the ddr code out into a dedicated bin file and pad to the end of SPL.
>
> What do you think?

Let's wait for some feedback from Stefano.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Stefano,

On Fri, Feb 23, 2018 at 6:46 AM, Stefano Babic  wrote:

>> Do you plan to post a new version for the patch that adds the mx8mq evk 
>> support?
>
> Do you mean to get it in 2018.03 ? The merge window is already closed, I
> am checking patches for fixes (if you see I missed something, raise a
> hand as usual...), but without adding new stuff. I do not want to put
> Peng under pressure while I am sure that MX8MQ EVK will be postponed in
> next release.

I was thinking about getting the mx8mq evk support into 2018.05. I
understand we are very close to the release now.

If you have some suggestions on how we can improve the DDR
configuration mechanism for mx8mq, please let us know.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Fabio,

On 22/02/2018 17:40, Fabio Estevam wrote:
> Hi Peng,
> 
> On Sun, Feb 4, 2018 at 7:42 AM, Stefano Babic  wrote:
> 
>> I have merged most of the series, Patch 2 up to patch 30, leaving out
>> just the last one for the EVK. Building mx8evk is fine, I have just
>> noted a couple of checkpatch warnings in mx8mq_evk.h
>> (CONFIG_EXTRA_SETTINGS, line too long). You could fix as well in next
>> post. The rest of patches is fine and will part of my next PR.
> 
> Do you plan to post a new version for the patch that adds the mx8mq evk 
> support?

Do you mean to get it in 2018.03 ? The merge window is already closed, I
am checking patches for fixes (if you see I missed something, raise a
hand as usual...), but without adding new stuff. I do not want to put
Peng under pressure while I am sure that MX8MQ EVK will be postponed in
next release.

Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Hi Fabio,
On Thu, Feb 22, 2018 at 01:40:47PM -0300, Fabio Estevam wrote:
>Hi Peng,
>
>On Sun, Feb 4, 2018 at 7:42 AM, Stefano Babic  wrote:
>
>> I have merged most of the series, Patch 2 up to patch 30, leaving out
>> just the last one for the EVK. Building mx8evk is fine, I have just
>> noted a couple of checkpatch warnings in mx8mq_evk.h
>> (CONFIG_EXTRA_SETTINGS, line too long). You could fix as well in next
>> post. The rest of patches is fine and will part of my next PR.
>
>Do you plan to post a new version for the patch that adds the mx8mq evk 
>support?

I was a bit busy on other things. Regarding the board support, I still
do not have a good idea about the DDR things. I am thinking moving
the ddr code out into a dedicated bin file and pad to the end of SPL.

What do you think?

Thanks,
Peng.

>
>Thanks
>___
>U-Boot mailing list
>U-Boot@lists.denx.de
>https://lists.denx.de/listinfo/u-boot

-- 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Peng,

On Sun, Feb 4, 2018 at 7:42 AM, Stefano Babic  wrote:

> I have merged most of the series, Patch 2 up to patch 30, leaving out
> just the last one for the EVK. Building mx8evk is fine, I have just
> noted a couple of checkpatch warnings in mx8mq_evk.h
> (CONFIG_EXTRA_SETTINGS, line too long). You could fix as well in next
> post. The rest of patches is fine and will part of my next PR.

Do you plan to post a new version for the patch that adds the mx8mq evk support?

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Peng, Fabio,

On 31/01/2018 11:30, Stefano Babic wrote:
> On 31/01/2018 11:25, Fabio Estevam wrote:
>> Hi Stefano,
>>
>> On Mon, Jan 22, 2018 at 2:20 PM, Stefano Babic  wrote:
>>
>>> ok, thanks, I will merge most of them.
>>
>> Do you think these patches could be applied to 2018.03?
>>
> 
> Yes, I wil lstart to merge these and the other pending patches.
> 

I have merged most of the series, Patch 2 up to patch 30, leaving out
just the last one for the EVK. Building mx8evk is fine, I have just
noted a couple of checkpatch warnings in mx8mq_evk.h
(CONFIG_EXTRA_SETTINGS, line too long). You could fix as well in next
post. The rest of patches is fine and will part of my next PR.

Thanks,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

On 31/01/2018 11:25, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Jan 22, 2018 at 2:20 PM, Stefano Babic  wrote:
> 
>> ok, thanks, I will merge most of them.
> 
> Do you think these patches could be applied to 2018.03?
> 

Yes, I wil lstart to merge these and the other pending patches.

Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Stefano,

On Mon, Jan 22, 2018 at 2:20 PM, Stefano Babic  wrote:

> ok, thanks, I will merge most of them.

Do you think these patches could be applied to 2018.03?

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Peng,

On 23/01/2018 02:54, Peng Fan wrote:
>>
>> I guess we will not have any improvement here, at least for first version.
> 
> I'll give a try to improve the ddr controller part. For ddr phy
> part, it is impossible to do that, it was autogenerated by tool
> from synopsys.

ok, I supposed something of this type - no human being will generate
this mess :-).

Anyway, this is fine if we can describe how it works. We have already
such a case with Altera SOCFPGA: the Altera's tool generates headers for
DDR and they are just imported into u-boot. Search for "qts"
directories, for example ./board/altera/arria5-socdk/qts. But if these
files are generated, we should also be sure that we do not need to
change them in U-Boot: tool generates DDR files, and we import them in
U-Boot. If tool produces them in another format such as a table, we just
need a small converter (python, perl, ...) that translates the tables
into C header / files (as we already do for assembly, for example). In
this way the chain is not broken: synopsys generates the files, we
import them into U-Boot and this becomes straightforward for board
maintainers.

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Peng,

On 23/01/2018 03:24, Peng Fan wrote:
> On Mon, Jan 22, 2018 at 03:00:36PM +0100, Stefano Babic wrote:
>> Hi Peng,
>>

[snip]

>> On 10/01/2018 06:20, Peng Fan wrote:

>>> +Get the ddr firmware and tools
>>> +
>>> +Note: Better to use NXP released yocto to get the firmware in case
>>> +  there is new releases.
>>> +https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.2.bin
>>> +imx-mkimage: https://source.codeaurora.org/external/imx/imx-mkimage/
>>
>>
>> I am just asking which is the plan here. This is a fork of U-Boot's
>> mkimage tool. I did not see attempts to push changes to imximage mainline.
>>
>> Any thoughts ? This means that it is not possible inside U-Boot to
>> produce a U-Boot image, but we need an external tool that was *based* on
>> U-Boot code
> 
> I'll try to develop the support in u-boot, but I could not commit.
> The new format is a bit complicated.

Can it help if we introduce a new image format parallel to the older ?
This introduce a new tools/ that is suitable just for
i.MX8. I understand that merging with current code is difficult and it
is easy to introduce breakages.

> 
>>
>> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
>> it, but it is not used in further commands.
> 
> My bad. Diego's patch has that.

ok, thanks.

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

On Mon, Jan 22, 2018 at 03:00:36PM +0100, Stefano Babic wrote:
>Hi Peng,
>
>On 10/01/2018 06:20, Peng Fan wrote:
>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>> DRAM.
>> 
>> The boot log with Arm trusted firmware console enabled:
>> "
>> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
>> PMIC:  PFUZE100 ID=0x10
>> Normal Boot
>> Trying to boot from MMC2
>> NOTICE:  Configureing TZASC380
>> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
>> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
>> NOTICE:  sip svc init
>> 
>> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
>> 
>> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
>> Reset cause: POR
>> Model: Freescale i.MX8MQ EVK
>> DRAM:  3 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> Using default environment
>> 
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> u-boot=>
>> "
>
>If I see the output here, I am expecting the setup forthe working
>peripherals. Without ethernet working, why do we activate FEC and set
>the PHY ?
>
>I would suggest to start with the minimal (=that is, all that is
>working), adding later when peripherals will be successfully added and
>tested.
>
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Fabio Estevam 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/dts/Makefile|2 +
>>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>>  board/freescale/mx8mq_evk/Kconfig|   12 +
>>  board/freescale/mx8mq_evk/Makefile   |   12 +
>>  board/freescale/mx8mq_evk/README |   47 +
>>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
>> ++
>>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>>  board/freescale/mx8mq_evk/spl.c  |  230 +
>>  configs/mx8mq_evk_defconfig  |   27 +
>>  include/configs/mx8mq_evk.h  |  269 ++
>>  14 files changed, 2819 insertions(+)
>>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>>  create mode 100644 board/freescale/mx8mq_evk/README
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>>  create mode 100644 configs/mx8mq_evk_defconfig
>>  create mode 100644 include/configs/mx8mq_evk.h
>> 
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index a895c70284..299107977f 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>>  
>>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>>  
>> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
>> +
>>  dtb-$(CONFIG_RCAR_GEN3) += \
>>  r8a7795-h3ulcb.dtb \
>>  r8a7795-salvator-x.dtb \
>> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts 
>> b/arch/arm/dts/fsl-imx8mq-evk.dts
>> new file mode 100644
>> index 00..f0aa3485e6
>> --- /dev/null
>> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
>> @@ -0,0 +1,424 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>> + * Copyright 2017 NXP
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/* First 128KB is for PSCI ATF. */
>> +/memreserve/ 0x4000 0x0002;
>> +
>> +#include "fsl-imx8mq.dtsi"
>> +
>> +/ {
>> +model = "Freescale i.MX8MQ EVK";
>> +compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
>> +
>> +chosen {
>> +bootargs = "console=ttymxc0,115200 
>> earlycon=ec_imx6q,0x3086,115200";
>> +};
>> +
>> +regulators {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +reg_usdhc2_vmmc: usdhc2_vmmc {
>> +compatible = "regulator-fixed";
>> +regulator-name = 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Hi Stefano,
On Mon, Jan 22, 2018 at 01:13:17PM +0100, Stefano Babic wrote:
>Hi Peng,
>
>On 10/01/2018 06:20, Peng Fan wrote:
>> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
>> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
>> DRAM.
>> 
>> The boot log with Arm trusted firmware console enabled:
>> "
>> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
>> PMIC:  PFUZE100 ID=0x10
>> Normal Boot
>> Trying to boot from MMC2
>> NOTICE:  Configureing TZASC380
>> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
>> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
>> NOTICE:  sip svc init
>> 
>> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
>> 
>> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
>> Reset cause: POR
>> Model: Freescale i.MX8MQ EVK
>> DRAM:  3 GiB
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
>> Using default environment
>> 
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>> u-boot=>
>> "
>
>If I see the output here, I am expecting the setup forthe working
>peripherals. Without ethernet working, why do we activate FEC and set
>the PHY ?
>
>I would suggest to start with the minimal (=that is, all that is
>working), adding later when peripherals will be successfully added and
>tested.

ok. I'll minimize the changes.

>
>> 
>> Signed-off-by: Peng Fan 
>> Cc: Fabio Estevam 
>> Cc: Stefano Babic 
>> ---
>>  arch/arm/dts/Makefile|2 +
>>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>>  board/freescale/mx8mq_evk/Kconfig|   12 +
>>  board/freescale/mx8mq_evk/Makefile   |   12 +
>>  board/freescale/mx8mq_evk/README |   47 +
>>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
>> ++
>>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>>  board/freescale/mx8mq_evk/spl.c  |  230 +
>>  configs/mx8mq_evk_defconfig  |   27 +
>>  include/configs/mx8mq_evk.h  |  269 ++
>>  14 files changed, 2819 insertions(+)
>>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>>  create mode 100644 board/freescale/mx8mq_evk/README
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>>  create mode 100644 configs/mx8mq_evk_defconfig
>>  create mode 100644 include/configs/mx8mq_evk.h
>> 
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index a895c70284..299107977f 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>>  
>>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>>  
>> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
>> +
>>  dtb-$(CONFIG_RCAR_GEN3) += \
>>  r8a7795-h3ulcb.dtb \
>>  r8a7795-salvator-x.dtb \
>> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts 
>> b/arch/arm/dts/fsl-imx8mq-evk.dts
>> new file mode 100644
>> index 00..f0aa3485e6
>> --- /dev/null
>> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
>> @@ -0,0 +1,424 @@
>> +/*
>> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
>> + * Copyright 2017 NXP
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +/* First 128KB is for PSCI ATF. */
>> +/memreserve/ 0x4000 0x0002;
>> +
>> +#include "fsl-imx8mq.dtsi"
>> +
>> +/ {
>> +model = "Freescale i.MX8MQ EVK";
>> +compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
>> +
>> +chosen {
>> +bootargs = "console=ttymxc0,115200 
>> earlycon=ec_imx6q,0x3086,115200";
>> +};
>> +
>> +regulators {
>> +compatible = "simple-bus";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +reg_usdhc2_vmmc: usdhc2_vmmc {
>> +compatible = "regulator-fixed";
>> 

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Fabio,

On 22/01/2018 16:23, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic  wrote:
> 
>>> --- /dev/null
>>> +++ b/board/freescale/mx8mq_evk/README
>>> @@ -0,0 +1,47 @@
>>> +U-Boot for the NXP i.MX8MQ EVK board
>>> +
>>> +Quick Start
>>> +
>>> +- Build the ARM Trusted firmware binary
>>> +- Build U-Boot
>>> +- Get ddr fimware and tools
>>> +- Generate flash.bin using imx-mkimage
>>> +- Boot
>>> +
>>> +Get and Build the ARM Trusted firmware
>>> +
>>> +Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>>
>> This is currently not enough - master is empty, which branch should be
>> selected ?
> 
> Yes, the README from this patch does not allow us to create a bootable image.
> 
> Diego sent a patch today that puts more details so that we can really
> boot the mx8mevk board.
> 
>> Is this maintainable ?
>>
>> I am asking why this is coming from here and not from an official
>> source, like :
>>
>> https://github.com/ARM-software/arm-trusted-firmware
> 
> Agreed.
> 
>> I am just asking which is the plan here. This is a fork of U-Boot's
>> mkimage tool. I did not see attempts to push changes to imximage mainline.
>>
>> Any thoughts ? This means that it is not possible inside U-Boot to
>> produce a U-Boot image, but we need an external tool that was *based* on
>> U-Boot code
> 
> Agreed. In long term imx-mkimage should go away and we should just use
> the official mkimage tool.
> 
>> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
>> it, but it is not used in further commands.
> 
> Diego's patch clarifies this point as well.
> 
>> I guess we will not have any improvement here, at least for first
>> version. I cannot say this is optimal, because it becomes difficult to
>> add further MX8M targets.
>>
>> Just an example: dramtmgX contain timings, and they are computed from
>> the RAM chip (tRAS, and so on).
>>
>> The best way (and I hope, this will go on sometimes..) should be to add
>> a table for the chosen RAM chip and registers are then computed.
>>
>> It will be even ok if there is a tool(I guess, you or the DDR-team is
>> using such as tool) to derive registers value from chip datasheet.
>>
>> Fabio, what do you think about this ?
> 
> Yes, the current method expects too much DDR code for each board and
> does not seem to scale well.
> 
>> Im open to suggestions how to go on. The big isssues with the patchset
>> is IMHO the cryptical part with the LPDDR settings. We could start to
>> merge most of patches - they were already reviewed and they are freee of
>> comments.
>>
>> Fabio, do you have a best approach ?
> 
> Yes, I agree. Please start merging the patches of the series that were
> reviewed and are in good shape.


ok, thanks, I will merge most of them.

> 
> Then Peng can rework this current patch that adds the mx8mqevk board support.
> 
> Thanks
> 

Best regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam]

Hi Stefano,

On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic  wrote:

>> --- /dev/null
>> +++ b/board/freescale/mx8mq_evk/README
>> @@ -0,0 +1,47 @@
>> +U-Boot for the NXP i.MX8MQ EVK board
>> +
>> +Quick Start
>> +
>> +- Build the ARM Trusted firmware binary
>> +- Build U-Boot
>> +- Get ddr fimware and tools
>> +- Generate flash.bin using imx-mkimage
>> +- Boot
>> +
>> +Get and Build the ARM Trusted firmware
>> +
>> +Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>
> This is currently not enough - master is empty, which branch should be
> selected ?

Yes, the README from this patch does not allow us to create a bootable image.

Diego sent a patch today that puts more details so that we can really
boot the mx8mevk board.

> Is this maintainable ?
>
> I am asking why this is coming from here and not from an official
> source, like :
>
> https://github.com/ARM-software/arm-trusted-firmware

Agreed.

> I am just asking which is the plan here. This is a fork of U-Boot's
> mkimage tool. I did not see attempts to push changes to imximage mainline.
>
> Any thoughts ? This means that it is not possible inside U-Boot to
> produce a U-Boot image, but we need an external tool that was *based* on
> U-Boot code

Agreed. In long term imx-mkimage should go away and we should just use
the official mkimage tool.

> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
> it, but it is not used in further commands.

Diego's patch clarifies this point as well.

> I guess we will not have any improvement here, at least for first
> version. I cannot say this is optimal, because it becomes difficult to
> add further MX8M targets.
>
> Just an example: dramtmgX contain timings, and they are computed from
> the RAM chip (tRAS, and so on).
>
> The best way (and I hope, this will go on sometimes..) should be to add
> a table for the chosen RAM chip and registers are then computed.
>
> It will be even ok if there is a tool(I guess, you or the DDR-team is
> using such as tool) to derive registers value from chip datasheet.
>
> Fabio, what do you think about this ?

Yes, the current method expects too much DDR code for each board and
does not seem to scale well.

> Im open to suggestions how to go on. The big isssues with the patchset
> is IMHO the cryptical part with the LPDDR settings. We could start to
> merge most of patches - they were already reviewed and they are freee of
> comments.
>
> Fabio, do you have a best approach ?

Yes, I agree. Please start merging the patches of the series that were
reviewed and are in good shape.

Then Peng can rework this current patch that adds the mx8mqevk board support.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Stefano Babic]

Hi Peng,

On 10/01/2018 06:20, Peng Fan wrote:
> Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
> firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
> DRAM.
> 
> The boot log with Arm trusted firmware console enabled:
> "
> U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
> PMIC:  PFUZE100 ID=0x10
> Normal Boot
> Trying to boot from MMC2
> NOTICE:  Configureing TZASC380
> NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
> NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
> NOTICE:  sip svc init
> 
> U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)
> 
> CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
> Reset cause: POR
> Model: Freescale i.MX8MQ EVK
> DRAM:  3 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> Using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> u-boot=>
> "

If I see the output here, I am expecting the setup forthe working
peripherals. Without ethernet working, why do we activate FEC and set
the PHY ?

I would suggest to start with the minimal (=that is, all that is
working), adding later when peripherals will be successfully added and
tested.

> 
> Signed-off-by: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile|2 +
>  arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
>  arch/arm/include/asm/arch-mx8m/ddr.h |9 +
>  arch/arm/mach-imx/mx8m/Kconfig   |   12 +
>  board/freescale/mx8mq_evk/Kconfig|   12 +
>  board/freescale/mx8mq_evk/Makefile   |   12 +
>  board/freescale/mx8mq_evk/README |   47 +
>  board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
>  board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 
> ++
>  board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
>  board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
>  board/freescale/mx8mq_evk/spl.c  |  230 +
>  configs/mx8mq_evk_defconfig  |   27 +
>  include/configs/mx8mq_evk.h  |  269 ++
>  14 files changed, 2819 insertions(+)
>  create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
>  create mode 100644 board/freescale/mx8mq_evk/Kconfig
>  create mode 100644 board/freescale/mx8mq_evk/Makefile
>  create mode 100644 board/freescale/mx8mq_evk/README
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
>  create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
>  create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
>  create mode 100644 board/freescale/mx8mq_evk/spl.c
>  create mode 100644 configs/mx8mq_evk_defconfig
>  create mode 100644 include/configs/mx8mq_evk.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a895c70284..299107977f 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>  
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
>  
> +dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
> +
>  dtb-$(CONFIG_RCAR_GEN3) += \
>   r8a7795-h3ulcb.dtb \
>   r8a7795-salvator-x.dtb \
> diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts b/arch/arm/dts/fsl-imx8mq-evk.dts
> new file mode 100644
> index 00..f0aa3485e6
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8mq-evk.dts
> @@ -0,0 +1,424 @@
> +/*
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +
> +/* First 128KB is for PSCI ATF. */
> +/memreserve/ 0x4000 0x0002;
> +
> +#include "fsl-imx8mq.dtsi"
> +
> +/ {
> + model = "Freescale i.MX8MQ EVK";
> + compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
> +
> + chosen {
> + bootargs = "console=ttymxc0,115200 
> earlycon=ec_imx6q,0x3086,115200";
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_usdhc2_vmmc: usdhc2_vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> +

[U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Peng Fan]

Add i.MX8MQ EVK support. SPL will initialize ddr and load ddr phy
firmware. Then loading FIT image, ATF to OCRAM, U-Boot and DTB to
DRAM.

The boot log with Arm trusted firmware console enabled:
"
U-Boot SPL 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56)
PMIC:  PFUZE100 ID=0x10
Normal Boot
Trying to boot from MMC2
NOTICE:  Configureing TZASC380
NOTICE:  BL31: v1.4(release):o8.0.0_1.3.0_8m-prc-20171211-6-g54fb0797-dirty
NOTICE:  BL31: Built : 07:17:16, Jan  8 2018
NOTICE:  sip svc init

U-Boot 2018.01-00038-gbd426c08ea (Jan 10 2018 - 13:14:56 +0800)

CPU:   Freescale i.MX8MQ rev2.0 at 1000 MHz
Reset cause: POR
Model: Freescale i.MX8MQ EVK
DRAM:  3 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
u-boot=>
"

Signed-off-by: Peng Fan 
Cc: Fabio Estevam 
Cc: Stefano Babic 
---
 arch/arm/dts/Makefile|2 +
 arch/arm/dts/fsl-imx8mq-evk.dts  |  424 +
 arch/arm/include/asm/arch-mx8m/ddr.h |9 +
 arch/arm/mach-imx/mx8m/Kconfig   |   12 +
 board/freescale/mx8mq_evk/Kconfig|   12 +
 board/freescale/mx8mq_evk/Makefile   |   12 +
 board/freescale/mx8mq_evk/README |   47 +
 board/freescale/mx8mq_evk/ddr/ddr_init.c |  246 +
 board/freescale/mx8mq_evk/ddr/ddrphy_train.c | 1272 ++
 board/freescale/mx8mq_evk/ddr/helper.c   |  101 ++
 board/freescale/mx8mq_evk/mx8mq_evk.c|  156 
 board/freescale/mx8mq_evk/spl.c  |  230 +
 configs/mx8mq_evk_defconfig  |   27 +
 include/configs/mx8mq_evk.h  |  269 ++
 14 files changed, 2819 insertions(+)
 create mode 100644 arch/arm/dts/fsl-imx8mq-evk.dts
 create mode 100644 board/freescale/mx8mq_evk/Kconfig
 create mode 100644 board/freescale/mx8mq_evk/Makefile
 create mode 100644 board/freescale/mx8mq_evk/README
 create mode 100644 board/freescale/mx8mq_evk/ddr/ddr_init.c
 create mode 100644 board/freescale/mx8mq_evk/ddr/ddrphy_train.c
 create mode 100644 board/freescale/mx8mq_evk/ddr/helper.c
 create mode 100644 board/freescale/mx8mq_evk/mx8mq_evk.c
 create mode 100644 board/freescale/mx8mq_evk/spl.c
 create mode 100644 configs/mx8mq_evk_defconfig
 create mode 100644 include/configs/mx8mq_evk.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a895c70284..299107977f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -391,6 +391,8 @@ dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
 
 dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
 
+dtb-$(CONFIG_ARCH_MX8M) += fsl-imx8mq-evk.dtb
+
 dtb-$(CONFIG_RCAR_GEN3) += \
r8a7795-h3ulcb.dtb \
r8a7795-salvator-x.dtb \
diff --git a/arch/arm/dts/fsl-imx8mq-evk.dts b/arch/arm/dts/fsl-imx8mq-evk.dts
new file mode 100644
index 00..f0aa3485e6
--- /dev/null
+++ b/arch/arm/dts/fsl-imx8mq-evk.dts
@@ -0,0 +1,424 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x4000 0x0002;
+
+#include "fsl-imx8mq.dtsi"
+
+/ {
+   model = "Freescale i.MX8MQ EVK";
+   compatible = "fsl,imx8mq-evk", "fsl,imx8mq";
+
+   chosen {
+   bootargs = "console=ttymxc0,115200 
earlycon=ec_imx6q,0x3086,115200";
+   };
+
+   regulators {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   reg_usdhc2_vmmc: usdhc2_vmmc {
+   compatible = "regulator-fixed";
+   regulator-name = "VSD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+   };
+
+   pwmleds {
+   compatible = "pwm-leds";
+
+   ledpwm2 {
+   label = "PWM2";
+   pwms = < 0 5>;
+   max-brightness = <255>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+
+   imx8mq-evk {
+   pinctrl_fec1: fec1grp {
+   fsl,pins = <
+   MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+