Re: [U-Boot] [PATCHv4 12/12] pci: ls_pcie_g4: add Workaround for A-011452

2019-03-16 Thread Prabhakar Kushwaha 

> -Original Message-
> From: Z.q. Hou
> Sent: Wednesday, March 13, 2019 8:25 PM
> To: u-boot@lists.denx.de; bmeng...@gmail.com; albert.u.b...@aribaud.net;
> Priyanka Jain ; York Sun ;
> sriram.d...@nxp.com; yamada.masah...@socionext.com; Prabhakar
> Kushwaha ; Mingkai Hu
> ; M.h. Lian 
> Subject: RE: [PATCHv4 12/12] pci: ls_pcie_g4: add Workaround for A-011452
> 
> Hi All,
> 
> Please ignore this patch, rev1.0 will not be production.
> 

I request you to resend your patch-set with the patches which you want to 
reviewed and accepted.
Please use [RESEND] in subject.

--pk 

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

Re: [U-Boot] mpc85xx, mpc86xx: device tree model

2019-03-16 Thread Tom Rini 
On Sun, Mar 17, 2019 at 03:01:32AM +, Prabhakar Kushwaha wrote:
> 
> > -Original Message-
> > From: Tom Rini 
> > Sent: Friday, March 15, 2019 9:36 PM
> > To: Prabhakar Kushwaha 
> > Cc: u-boot@lists.denx.de; York Sun 
> > Subject: Re: mpc85xx, mpc86xx: device tree model
> > 
> > On Fri, Mar 15, 2019 at 05:05:06AM +, Prabhakar Kushwaha wrote:
> > 
> > > Hi Tom,
> > >
> > > I am seeing following type of build warnings for MMC.
> > >
> > > += WARNING == This board
> > does
> > > +not use CONFIG_DM_MMC. Please update the board to use
> > CONFIG_DM_MMC
> > > +before the v2019.04 release.
> > > +Failure to update by the deadline may result in board removal.
> > > +See doc/driver-model/MIGRATION.txt for more info.
> > >
> > > Considering "number" of powerpc platform are not migrated to deice
> > > tree. They can not be migrated to CONFIG_DM_MMC withing v2019.04
> > > time-frame (considering rc4 is on 18th march).
> > > v2019.07 looks feasible for removing all warning which includes
> > > CONFIG_DM_USB, CONFIG_DM_SCSI, CONFIG_DM_PCI,
> > CONFIG_DM_SPI_FLASH and
> > > CONFIG_DM_MMC.
> > >
> > > is there any plan of removing boards which don't have CONFIG_DM_MMC
> > > for v2019.04?
> > 
> > Good question.  Where exactly are we with getting more of PowerPC brought up
> > to date with these requirements?  
> 
> There are only 2 platforms which are on device tree model. 
> 
> Rest (65 targets) still need to be ported. Here 13 are non-NXP and 52 NXP. 
> I am working internally to get staffed for porting of NXP platform. 
> For non-NXP , I will reaching platform owners for migration.
> 
> It will take some time.  

OK.

> > I've mentioned before and will say it again,
> > I'm inclined to start marking stuff as 'depends on BROKEN' for a release 
> > and then
> > pulling the underlying code (so in this case, non-DM code from
> > drivers/mmc/mmc.c and other MMC-core) for the release following.
> 
> Is enabling 'depends on BROKEN', still allow platform to build and use?

Yes, but it'll only buy a little bit of time.  Thanks!

-- 
Tom


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

Re: [U-Boot] mpc85xx, mpc86xx: device tree model

2019-03-16 Thread Prabhakar Kushwaha 

> -Original Message-
> From: Tom Rini 
> Sent: Friday, March 15, 2019 9:36 PM
> To: Prabhakar Kushwaha 
> Cc: u-boot@lists.denx.de; York Sun 
> Subject: Re: mpc85xx, mpc86xx: device tree model
> 
> On Fri, Mar 15, 2019 at 05:05:06AM +, Prabhakar Kushwaha wrote:
> 
> > Hi Tom,
> >
> > I am seeing following type of build warnings for MMC.
> >
> > += WARNING == This board
> does
> > +not use CONFIG_DM_MMC. Please update the board to use
> CONFIG_DM_MMC
> > +before the v2019.04 release.
> > +Failure to update by the deadline may result in board removal.
> > +See doc/driver-model/MIGRATION.txt for more info.
> >
> > Considering "number" of powerpc platform are not migrated to deice
> > tree. They can not be migrated to CONFIG_DM_MMC withing v2019.04
> > time-frame (considering rc4 is on 18th march).
> > v2019.07 looks feasible for removing all warning which includes
> > CONFIG_DM_USB, CONFIG_DM_SCSI, CONFIG_DM_PCI,
> CONFIG_DM_SPI_FLASH and
> > CONFIG_DM_MMC.
> >
> > is there any plan of removing boards which don't have CONFIG_DM_MMC
> > for v2019.04?
> 
> Good question.  Where exactly are we with getting more of PowerPC brought up
> to date with these requirements?  

There are only 2 platforms which are on device tree model. 

Rest (65 targets) still need to be ported. Here 13 are non-NXP and 52 NXP. 
I am working internally to get staffed for porting of NXP platform. 
For non-NXP , I will reaching platform owners for migration.

It will take some time.  

> I've mentioned before and will say it again,
> I'm inclined to start marking stuff as 'depends on BROKEN' for a release and 
> then
> pulling the underlying code (so in this case, non-DM code from
> drivers/mmc/mmc.c and other MMC-core) for the release following.

Is enabling 'depends on BROKEN', still allow platform to build and use?

--pk




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

Re: [U-Boot] [PATCH] phy: ti: Init node before reading

2019-03-16 Thread Hannes Schmelzer 
"U-Boot"  schrieb am 16.03.2019 12:43:17:

> Von: Michal Simek 
> An: u-boot@lists.denx.de
> Kopie: Janine Hagemann , Joe Hershberger 
> , Hannes Schmelzer 
> Datum: 16.03.2019 12:43
> Betreff: [U-Boot] [PATCH] phy: ti: Init node before reading
> Gesendet von: "U-Boot" 
> 
> There is a need to fill node before clk_output_sel is setup.
> 
> Signed-off-by: Michal Simek 
> Acked-by: Siva Durga Prasad Paladugu 
> ---
> 
>  drivers/net/phy/ti.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: 


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

Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable

2019-03-16 Thread Simon Goldschmidt 



On 16.03.19 13:50, Marek Vasut wrote:

On 3/16/19 1:36 PM, Simon Goldschmidt wrote:



On Saturday, March 16, 2019, Marek Vasut mailto:ma...@denx.de>> wrote:

 On 3/16/19 9:23 AM, Simon Goldschmidt wrote:
 > Am 15.03.2019 um 22:20 schrieb Marek Vasut:
 >> On 3/15/19 8:44 PM, Simon Goldschmidt wrote:
 >>> To boot from fpga on socfpga gen5, we need to set
 >>> CONFIG_SPL_TEXT_BASE to
 >>> 0xC000 (hps2fpgaslaves base address).
 >>>
 >>> Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been
 >>> successful so
 >>> far, let's make this value overridable in socfpga_common.h, so that
 >>> we can
 >>> have different board configs override this in socfpga_common.h.
 >>>
 >>> Signed-off-by: Simon Goldschmidt
 mailto:simon.k.r.goldschm...@gmail.com>>
 >>
 >> Is this a fix for current release or new feature for next ?
 >
 > Yes, it's a fix for the current release. It's the only thing
 missing to
 > *finally* get mainline SPL booting from FPGA (on socfpga gen5).
 >
 > As written in the log, the original plan was to move
 > CONFIG_SPL_TEXT_BASE to Kconfig completely, but that didn't work out
 > (still), which is why we have to do it in a different way.
 >
 > I could provide a new board config to boot from FPGA if you want, but
 > that did not make much sense to me as the FPGA image would be
 missing...

 Well, applied.


Thanks.
  



 That said, do you plan to work on the Kconfig conversion further ?
 What's the problem there ?


I started that conversion (still in patchwork) but Tom said it produced
errors
and he kind of took it further. I'm not really on track what's still
missing.

But of course I would still prefer the Kconfig version instead of this
#ifndef...


Always :)



What's the status here, Tom? Anything I can do? Should I try again now 
with my original approach of just using moveconfig.py?


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

Re: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings

2019-03-16 Thread Tom Rini 
On Sat, Mar 16, 2019 at 09:23:01PM +0100, Marek Vasut wrote:
> On 3/16/19 2:50 AM, Tom Rini wrote:
> > On Fri, Mar 15, 2019 at 06:39:23PM +0100, Marek Vasut wrote:
> >> On 3/14/19 2:01 AM, Tom Rini wrote:
> >>> On Thu, Mar 14, 2019 at 01:20:09AM +0100, Marek Vasut wrote:
>  On 3/13/19 8:42 PM, Tom Rini wrote:
> > On Wed, Mar 13, 2019 at 07:23:15PM +0100, Marek Vasut wrote:
> >> On 3/13/19 5:01 PM, Tom Rini wrote:
> >>> On Wed, Mar 13, 2019 at 12:30:59PM +0100, Marek Vasut wrote:
>  On 3/13/19 12:29 PM, Tom Rini wrote:
> > On Wed, Mar 13, 2019 at 12:27:38PM +0100, Marek Vasut wrote:
> >> On 3/13/19 12:25 PM, Tom Rini wrote:
> >>> On Wed, Mar 13, 2019 at 12:20:49PM +0100, Marek Vasut wrote:
>  On 3/13/19 12:19 PM, Tom Rini wrote:
> > On Wed, Mar 13, 2019 at 05:08:14AM +0100, Marek Vasut wrote:
> >
> >> Fix the following spit from pytest:
> >>
> >> u-boot/test/py/conftest.py:438: RemovedInPytest4Warning: 
> >> MarkInfo objects are deprecated as they contain merged marks 
> >> which are hard to deal with correctly.
> >>   Please use node.get_closest_marker(name) or 
> >> node.iter_markers(name).
> >>   Docs: 
> >> https://docs.pytest.org/en/latest/mark.html#updating-code
> >> for board in mark.args:
> >>
> >> In both cases, the later suggestion is applicable.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Igor Opaniuk 
> >> Cc: Tom Rini 
> >> Cc: Simon Glass 
> >
> > Deferred, for now we don't support newer pytest than 2.8.7 and 
> > you'll
> > need to use virtualenv to set that up if needed.  There is not, 
> > AFAICT,
> > a way to support both versions.
> 
>  That's what's in debian testing though, so maybe we need to 
>  support it
>  somehow.
> >>>
> >>> Yes, I'm _very_ frustrated at the speed at which pytest went from 
> >>> "this
> >>> is the API" to "this API is deprecated" to "this API doesn't work 
> >>> and
> >>> here's the new, incompatible API".  Debian/testing needs to use
> >>> virtualenv to setup a python area with older pytest installed, 
> >>> just like
> >>> we do in .travis.yml.
> >>
> >> Can't we rather have people use the new APIs and virtualenv new 
> >> python?
> >
> > Not as easily, no.  Debian/testing may have something much newer but
> > Debian/stable doesn't, and I don't know what Ubuntu/18.04 has 
> > off-hand
> > but it's probably inbetween and so on.
> 
>  While I'm not a python expert, shouldn't virtualenv help with that ?
> >>>
> >>> Yes, and breaking old setups is usually frowned upon and making new
> >>> setups conform to the existing ways is how things are usually done.
> >>
> >> If you use venv with old setup, won't that give you the new python you
> >> need ?
> >
> > No, you don't need to.  Travis is special in that it's based on Ubuntu
> > 14.04 () and so we needed to use pip there to setup anything, and
> > have for forever.  That in turn lead to us hitting this problem a while
> > back, when "pip install pytest" first gave us something where the old
> > behavior became a fatal error.  That leads to installing the last
> > version before pytest starts to complain about changing APIs.  Normally
> > old distributions however ship with 2.8.7 anyways and don't need
> > virtaulenv.
> 
>  I don't think I get your point here. Sure, old distros might need to
>  change and start using virtualenv because the software is just too old.
>  We cannot support all kinds of old stuff. If the API we're using is
>  getting deprecated, let's just switch to the new one and ask the users
>  of old software to upgrade (?).
> >>>
> >>> My point is that "pin to a newer pytest version" is not something I want
> >>> right now.  It will break existing setups and provide nothing in return.
> >>
> >> Besides, using latest code instead of old stuff, as we should ?
> > 
> > We should?  What's the reason we need to upgrade?  What problem we have
> > is being fixed?
> 
> With this reasoning, we could've stuck to gcc 2.95 too though.
> Why didn't we ?
> 
> >> If your existing setup breaks, maybe you should update your existing setup.
> > 
> > No, we don't break existing setups.
> 
> Heh? Seems to happen all the time with the DM/DT stuff.
> 
> >>> There's not some new feature of pytest we're missing out on.  My take
> >>> away from all of this is that we need to move the whole thing into being
> >>> wrapped up, for everyone, as we cannot expect random community

Re: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings

2019-03-16 Thread Marek Vasut 
On 3/16/19 2:50 AM, Tom Rini wrote:
> On Fri, Mar 15, 2019 at 06:39:23PM +0100, Marek Vasut wrote:
>> On 3/14/19 2:01 AM, Tom Rini wrote:
>>> On Thu, Mar 14, 2019 at 01:20:09AM +0100, Marek Vasut wrote:
 On 3/13/19 8:42 PM, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 07:23:15PM +0100, Marek Vasut wrote:
>> On 3/13/19 5:01 PM, Tom Rini wrote:
>>> On Wed, Mar 13, 2019 at 12:30:59PM +0100, Marek Vasut wrote:
 On 3/13/19 12:29 PM, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 12:27:38PM +0100, Marek Vasut wrote:
>> On 3/13/19 12:25 PM, Tom Rini wrote:
>>> On Wed, Mar 13, 2019 at 12:20:49PM +0100, Marek Vasut wrote:
 On 3/13/19 12:19 PM, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 05:08:14AM +0100, Marek Vasut wrote:
>
>> Fix the following spit from pytest:
>>
>> u-boot/test/py/conftest.py:438: RemovedInPytest4Warning: 
>> MarkInfo objects are deprecated as they contain merged marks 
>> which are hard to deal with correctly.
>>   Please use node.get_closest_marker(name) or 
>> node.iter_markers(name).
>>   Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
>> for board in mark.args:
>>
>> In both cases, the later suggestion is applicable.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Igor Opaniuk 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>
> Deferred, for now we don't support newer pytest than 2.8.7 and 
> you'll
> need to use virtualenv to set that up if needed.  There is not, 
> AFAICT,
> a way to support both versions.

 That's what's in debian testing though, so maybe we need to 
 support it
 somehow.
>>>
>>> Yes, I'm _very_ frustrated at the speed at which pytest went from 
>>> "this
>>> is the API" to "this API is deprecated" to "this API doesn't work 
>>> and
>>> here's the new, incompatible API".  Debian/testing needs to use
>>> virtualenv to setup a python area with older pytest installed, just 
>>> like
>>> we do in .travis.yml.
>>
>> Can't we rather have people use the new APIs and virtualenv new 
>> python?
>
> Not as easily, no.  Debian/testing may have something much newer but
> Debian/stable doesn't, and I don't know what Ubuntu/18.04 has off-hand
> but it's probably inbetween and so on.

 While I'm not a python expert, shouldn't virtualenv help with that ?
>>>
>>> Yes, and breaking old setups is usually frowned upon and making new
>>> setups conform to the existing ways is how things are usually done.
>>
>> If you use venv with old setup, won't that give you the new python you
>> need ?
>
> No, you don't need to.  Travis is special in that it's based on Ubuntu
> 14.04 () and so we needed to use pip there to setup anything, and
> have for forever.  That in turn lead to us hitting this problem a while
> back, when "pip install pytest" first gave us something where the old
> behavior became a fatal error.  That leads to installing the last
> version before pytest starts to complain about changing APIs.  Normally
> old distributions however ship with 2.8.7 anyways and don't need
> virtaulenv.

 I don't think I get your point here. Sure, old distros might need to
 change and start using virtualenv because the software is just too old.
 We cannot support all kinds of old stuff. If the API we're using is
 getting deprecated, let's just switch to the new one and ask the users
 of old software to upgrade (?).
>>>
>>> My point is that "pin to a newer pytest version" is not something I want
>>> right now.  It will break existing setups and provide nothing in return.
>>
>> Besides, using latest code instead of old stuff, as we should ?
> 
> We should?  What's the reason we need to upgrade?  What problem we have
> is being fixed?

With this reasoning, we could've stuck to gcc 2.95 too though.
Why didn't we ?

>> If your existing setup breaks, maybe you should update your existing setup.
> 
> No, we don't break existing setups.

Heh? Seems to happen all the time with the DM/DT stuff.

>>> There's not some new feature of pytest we're missing out on.  My take
>>> away from all of this is that we need to move the whole thing into being
>>> wrapped up, for everyone, as we cannot expect random community python
>>> modules to remove an API in an extremely quick fashion.  If you're
>>> motivated enough over this to go off and do that, yes, sure.  But I will
>>> not take a patch this patch as-is, as it breaks travis-ci.
>>
>> Cool, and without this patch, all the tests fail on debian testing.
> 
>

Re: [U-Boot] passing info from SPL to U-Boot

2019-03-16 Thread Simon Glass 
Hi Wolfgang,

On Fri, 15 Mar 2019 at 02:34, Wolfgang Denk  wrote:
>
> Dear Simon,
>
> In message 
>  you 
> wrote:
> >
> > I think it is a reasonable idea to allow the gd region to pass from
> > TPL -> SPL -> U-Boot. But we'll need to remove use of
> > CONFIG_IS_ENABLED(), or put shared things at the beginning of the
> > structure.
>
> Indeed. And/or split things up in "common" stuff and optional /
> config dependent things.
>
> > We need the concept of 'am I the first thing to run'. This is
> > implemented in bloblist as u_boot_first_phase() - see spl.h. If this
> > is true, we must set up the data structure. If false we must find one
> > set up by a previous phase and use it. Bloblist handles this, but
> > perhaps gd could as well?
>
> I wonder why we need 4 different ways of doing basically the same
> thing.
>
> First, we have GD, which exists since the dawn of U-Boot, which was
> intended to pass data between boot stages (by then, before and after
> relocation), but apparently it has never been used for passing
> information between SPL and U-Boot proper.

That's right. It is always zeroed these days at the start of each
phase. So I think work is needed if we want to use this.

Also I don't think we can assume that gd stays in the same place
through all phases of U-Boot. Probably we can keep it in the same
place in TPL, SPL and U-Boot pre-relocation, then move it to SDRAM
during relocation.

>
> Then you added the bloblist thingy.  It's not really clear what it's
> intentions are - I see the commits, but I can't find what you want
> to use it for or what design you have in mind.  It's too complicated
> for passing just a few data, but apparently you find it necessary to
> make it secure enough that you add version, magic and checksum
> (which makes it necessary to have CRC32 in SPL...).  Also, I wonder
> how the search mechanism effects boot time...

This is designed for things that need to past structs between phases.
For example, verified boot may start processing in TPL and then pass
information to SPL and then to U-Boot proper. This may involve quite a
bit of info, so it is in a C structure. It isn't really suitable to
put this entire structure in gd IMO, since that struct is pretty
small.

See doc/README.bloblist:

 A bloblist provides a way to store collections of binary information
(blobs) in
 a central structure. Each record of information is assigned a tag so that its
 owner can find it and update it. Each record is generally described by a C
 structure defined by the code that owns it.

Maybe this should have more detail?

The version, magic and checksum are to ensure that the data is not
corrupted by mistake, which as you know can happen very easily with
fixed-position data structures. The search is pretty quick once the
checksum is done, just running through a few pointers. I suppose we
could make the checksum optional.

>
> An then there is commit b0edea3c27 with the spl_handoff thing.  I
> can't decide whether this is intended as a general feature or a
> separate, SPL specific mechanism.  And more questions - if we pass
> the handoff pointer in GD, why all the effort - why don't we just
> make sure GD is passed properly?  The fact that there is no use case
> at all in mainline U-Boot makes it really hard to understand your
> intentions.

That actually uses the bloblist, putting an SPL struct in there,
intended to hold things like the SDRAM config or boot options
discovered in SPL. At present we have a few ad-hoc ways of

>
> And finally there is bootstage with it's own mechanism of
> information passing.

Yes, and this is ad-hoc too. I would like to move it to bloblist.

>
>
> Can we not unify these, and use one common method, please?

I think we might end up with gd (once this work is done) and bloblist.
For now I feel that bloblist has a purpose but let's see how it goes
with the gd work.

>
>
> > Also consider the scenario where there is a read-only TPL programmed
> > in manufacture that never changes, and a read-write SPL +  U-Boot that
> > can be upgraded in the field. In this case they may eventually end up
> > being built with different versions of U-Boot. The bloblist structure
> > is intended to handle this by at least checking that the size matches.
>
> You also have the version field there, right?  Who not (also)
> checking this?

Yes it should check this, at least once we actually have a version 1 :-)

>
> > Related, I feel that we should figure out how to use registers to pass
> > addresses from SPL to U-Boot. On ARM we could use r0 to pass the value
> > of gd, perhaps.
>
> There is no need to.  GD already has a well-defined register which
> has been reserved exclusively for this use - on ARM, it's R9.

Yes, but I'm not sure this is portable. E.g. on x86 this can't be used
in 64-bit mode, so passing info from 32-bit SPL to 64-bit U-Boot is
not possible (I believe). Using a normal register might be better, but
in any case this is going to be arch-specific.

In any case, I was

[U-Boot] Sunxi H5 and CONFIG_ENV_IS_IN_MMC problem

2019-03-16 Thread g4 
Greetings

Our board has an AllWinner H5 with SPI flash and eMMC. Since SPI flash
support for 'saveenv' is not currently mainline, I thought I'd simply use
one of the eMMC boot blocks to persist the environment. However I keep
running into image size problems [1]

Not being a U-Boot ninja, the defconfig [2] is about as minimal as I believe
I can make it. (Network support is required for TFTP/NFS operations) Does
the panel have any suggestions for getting the desired configuration built?

MTIA.

Jerry.
snip
--
[1]
MKSUNXI spl/sunxi-spl.bin
  MKIMAGE u-boot.img
  MKIMAGE u-boot-dtb.img
/home/moi/src/u-boot/denx/"board/sunxi/mksunxi_fit_atf.sh" \
arch/arm/dts/anemos-sc5.dtb > u-boot.its
  MKIMAGE u-boot.itb
u-boot.itb exceeds file size limit:
  limit:  516096 bytes
  actual: 519448 bytes
  excess: 3352 bytes
/home/moi/src/u-boot/denx/Makefile:1204: recipe for target 'u-boot.itb'
failed

snip--
[2]
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_SPL=y
CONFIG_MACH_SUN50I_H5=y
CONFIG_DRAM_CLK=504
CONFIG_DRAM_ZQ=3881977
CONFIG_DRAM_ODT_EN=y
CONFIG_MACPWR="PD6"
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_SPL_SPI_SUNXI=y
CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI_FLASH_TINY=y
CONFIG_DEFAULT_DEVICE_TREE="anemos-sc5"
CONFIG_ENV_IS_IN_MMC=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_MTD=y
CONFIG_MTD_DEVICE=y
CONFIG_SUN8I_EMAC=y
CONFIG_USB_EHCI_HCD=y
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y

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

Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable

2019-03-16 Thread Marek Vasut 
On 3/16/19 1:36 PM, Simon Goldschmidt wrote:
> 
> 
> On Saturday, March 16, 2019, Marek Vasut  > wrote:
> 
> On 3/16/19 9:23 AM, Simon Goldschmidt wrote:
> > Am 15.03.2019 um 22:20 schrieb Marek Vasut:
> >> On 3/15/19 8:44 PM, Simon Goldschmidt wrote:
> >>> To boot from fpga on socfpga gen5, we need to set
> >>> CONFIG_SPL_TEXT_BASE to
> >>> 0xC000 (hps2fpgaslaves base address).
> >>>
> >>> Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been
> >>> successful so
> >>> far, let's make this value overridable in socfpga_common.h, so that
> >>> we can
> >>> have different board configs override this in socfpga_common.h.
> >>>
> >>> Signed-off-by: Simon Goldschmidt
>  >
> >>
> >> Is this a fix for current release or new feature for next ?
> >
> > Yes, it's a fix for the current release. It's the only thing
> missing to
> > *finally* get mainline SPL booting from FPGA (on socfpga gen5).
> >
> > As written in the log, the original plan was to move
> > CONFIG_SPL_TEXT_BASE to Kconfig completely, but that didn't work out
> > (still), which is why we have to do it in a different way.
> >
> > I could provide a new board config to boot from FPGA if you want, but
> > that did not make much sense to me as the FPGA image would be
> missing...
> 
> Well, applied.
> 
> 
> Thanks.
>  
> 
> 
> That said, do you plan to work on the Kconfig conversion further ?
> What's the problem there ?
> 
> 
> I started that conversion (still in patchwork) but Tom said it produced
> errors
> and he kind of took it further. I'm not really on track what's still
> missing.
> 
> But of course I would still prefer the Kconfig version instead of this
> #ifndef...

Always :)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable

2019-03-16 Thread Simon Goldschmidt 
On Saturday, March 16, 2019, Marek Vasut  wrote:

> On 3/16/19 9:23 AM, Simon Goldschmidt wrote:
> > Am 15.03.2019 um 22:20 schrieb Marek Vasut:
> >> On 3/15/19 8:44 PM, Simon Goldschmidt wrote:
> >>> To boot from fpga on socfpga gen5, we need to set
> >>> CONFIG_SPL_TEXT_BASE to
> >>> 0xC000 (hps2fpgaslaves base address).
> >>>
> >>> Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been
> >>> successful so
> >>> far, let's make this value overridable in socfpga_common.h, so that
> >>> we can
> >>> have different board configs override this in socfpga_common.h.
> >>>
> >>> Signed-off-by: Simon Goldschmidt 
> >>
> >> Is this a fix for current release or new feature for next ?
> >
> > Yes, it's a fix for the current release. It's the only thing missing to
> > *finally* get mainline SPL booting from FPGA (on socfpga gen5).
> >
> > As written in the log, the original plan was to move
> > CONFIG_SPL_TEXT_BASE to Kconfig completely, but that didn't work out
> > (still), which is why we have to do it in a different way.
> >
> > I could provide a new board config to boot from FPGA if you want, but
> > that did not make much sense to me as the FPGA image would be missing...
>
> Well, applied.


Thanks.


>
> That said, do you plan to work on the Kconfig conversion further ?
> What's the problem there ?


I started that conversion (still in patchwork) but Tom said it produced
errors
and he kind of took it further. I'm not really on track what's still
missing.

But of course I would still prefer the Kconfig version instead of this
#ifndef...

Regards,
Simon


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

Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable

2019-03-16 Thread Marek Vasut 
On 3/16/19 9:23 AM, Simon Goldschmidt wrote:
> Am 15.03.2019 um 22:20 schrieb Marek Vasut:
>> On 3/15/19 8:44 PM, Simon Goldschmidt wrote:
>>> To boot from fpga on socfpga gen5, we need to set
>>> CONFIG_SPL_TEXT_BASE to
>>> 0xC000 (hps2fpgaslaves base address).
>>>
>>> Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been
>>> successful so
>>> far, let's make this value overridable in socfpga_common.h, so that
>>> we can
>>> have different board configs override this in socfpga_common.h.
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>
>> Is this a fix for current release or new feature for next ?
> 
> Yes, it's a fix for the current release. It's the only thing missing to
> *finally* get mainline SPL booting from FPGA (on socfpga gen5).
> 
> As written in the log, the original plan was to move
> CONFIG_SPL_TEXT_BASE to Kconfig completely, but that didn't work out
> (still), which is why we have to do it in a different way.
> 
> I could provide a new board config to boot from FPGA if you want, but
> that did not make much sense to me as the FPGA image would be missing...

Well, applied.

That said, do you plan to work on the Kconfig conversion further ?
What's the problem there ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] phy: ti: Init node before reading

2019-03-16 Thread Michal Simek 
There is a need to fill node before clk_output_sel is setup.

Signed-off-by: Michal Simek 
Acked-by: Siva Durga Prasad Paladugu 
---

 drivers/net/phy/ti.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 6db6edd0d0c8..10989dd40309 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -216,6 +216,10 @@ static int dp83867_of_init(struct phy_device *phydev)
 
/* Optional configuration */
 
+   node = phy_get_ofnode(phydev);
+   if (!ofnode_valid(node))
+   return -EINVAL;
+
/*
 * Keep the default value if ti,clk-output-sel is not set
 * or to high
@@ -225,10 +229,6 @@ static int dp83867_of_init(struct phy_device *phydev)
ofnode_read_u32_default(node, "ti,clk-output-sel",
DP83867_CLK_O_SEL_REF_CLK);
 
-   node = phy_get_ofnode(phydev);
-   if (!ofnode_valid(node))
-   return -EINVAL;
-
if (ofnode_read_bool(node, "ti,max-output-impedance"))
dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
else if (ofnode_read_bool(node, "ti,min-output-impedance"))
-- 
1.9.1

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

Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable

2019-03-16 Thread Simon Goldschmidt 

Am 15.03.2019 um 22:20 schrieb Marek Vasut:

On 3/15/19 8:44 PM, Simon Goldschmidt wrote:

To boot from fpga on socfpga gen5, we need to set CONFIG_SPL_TEXT_BASE to
0xC000 (hps2fpgaslaves base address).

Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been successful so
far, let's make this value overridable in socfpga_common.h, so that we can
have different board configs override this in socfpga_common.h.

Signed-off-by: Simon Goldschmidt 


Is this a fix for current release or new feature for next ?


Yes, it's a fix for the current release. It's the only thing missing to 
*finally* get mainline SPL booting from FPGA (on socfpga gen5).


As written in the log, the original plan was to move 
CONFIG_SPL_TEXT_BASE to Kconfig completely, but that didn't work out 
(still), which is why we have to do it in a different way.


I could provide a new board config to boot from FPGA if you want, but 
that did not make much sense to me as the FPGA image would be missing...


Regards,
Simon




---

  include/configs/socfpga_common.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 181af9b646..191204b27b 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -248,8 +248,10 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
   * 0xFFEz_ .. Malloc area (grows up to top)
   * 0xFFE3_ .. End of SRAM (top)
   */
+#ifndef CONFIG_SPL_TEXT_BASE
  #define CONFIG_SPL_TEXT_BASE  CONFIG_SYS_INIT_RAM_ADDR
  #define CONFIG_SPL_MAX_SIZE   CONFIG_SYS_INIT_RAM_SIZE
+#endif
  
  #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)

  /* SPL memory allocation configuration, this is for FAT implementation */






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

[U-Boot] [PATCH 2/2] ARM: mvebu: sync db-88f6820-amc.dts with Linux v5.0

2019-03-16 Thread Chris Packham 
Sync armada-385-db-88f6820-amc.dts with Linux. Retain the
u-boot,dm-pre-reloc and nand differences.

Signed-off-by: Chris Packham 
---

 arch/arm/dts/armada-385-db-88f6820-amc.dts | 184 +
 1 file changed, 82 insertions(+), 102 deletions(-)

diff --git a/arch/arm/dts/armada-385-db-88f6820-amc.dts 
b/arch/arm/dts/armada-385-db-88f6820-amc.dts
index c9ccbb57fff5..59a425f6b155 100644
--- a/arch/arm/dts/armada-385-db-88f6820-amc.dts
+++ b/arch/arm/dts/armada-385-db-88f6820-amc.dts
@@ -1,51 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
 /*
- * Device Tree file for Marvell Armada 385 development board
+ * Device Tree file for Marvell Armada 385 AMC board
  * (DB-88F6820-AMC)
  *
- * Copyright (C) 2014 Marvell
- *
- * Gregory CLEMENT 
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without
- * any warranty of any kind, whether express or implied.
- *
- * Or, alternatively,
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
+ * Copyright (C) 2017 Allied Telesis Labs
  */
 
 /dts-v1/;
 #include "armada-385.dtsi"
+
 #include 
 
 / {
model = "Marvell Armada 385 AMC";
-   compatible = "marvell,a385-amc", "marvell,armada385", 
"marvell,armada380";
+   compatible = "marvell,a385-db-amc", "marvell,armada385", 
"marvell,armada380";
 
chosen {
stdout-path = "serial0:115200n8";
@@ -60,90 +28,88 @@
 
memory {
device_type = "memory";
-   reg = <0x 0x8000>; /* 2 GB */
+   reg = <0x 0x8000>; /* 2GB */
};
 
soc {
ranges = ;
+   };
+};
 
-   internal-regs {
-   i2c@11000 {
-   clock-frequency = <10>;
-   u-boot,i2c-slave-addr = <0x0>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-   };
-
-   serial@12000 {
-   /*
-* Exported on the micro USB connector CON16
-* through an FTDI
-*/
+ {
+   u-boot,i2c-slave-addr = <0x0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
 
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-   u-boot,dm-pre-reloc;
-   };
+ {
+   /*
+* Exported on the micro USB connector CON3
+* through an FTDI
+*/
 
-   ethernet@34000 {
-   status = "okay";
-   phy = <>;
-   phy-mode = "sgmii";
-   };
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+   u-boot,dm-pre-reloc;
+};
 
-   usb@58000 {
-   status = "okay";
-   };
 
-   ethernet@7 {
-   pinctrl-names = "default";
-   /*
-* The Reference Clock 0 is used to provide a
-* clock to the PHY
-*/
-   pinctrl-0 = <_rgmii_pins>, <_clk0_pins>;
-

[U-Boot] [PATCH 1/2] ARM: mvebu: rename armada-385-amc.dts to armada-385-db-88f6820-amc.dts

2019-03-16 Thread Chris Packham 
This board was added to u-boot first but the Linux maintainers requested
a more descriptive name. Rename the file to match the Linux usage and
update the board defconfig.

Signed-off-by: Chris Packham 
---

 arch/arm/dts/Makefile   | 2 +-
 .../dts/{armada-385-amc.dts => armada-385-db-88f6820-amc.dts}   | 0
 configs/db-88f6820-amc_defconfig| 2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/arm/dts/{armada-385-amc.dts => armada-385-db-88f6820-amc.dts} 
(100%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2a040b20a539..9fa5c98a8240 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -101,7 +101,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-388-clearfog.dtb \
armada-388-gp.dtb   \
armada-388-helios4.dtb  \
-   armada-385-amc.dtb  \
+   armada-385-db-88f6820-amc.dtb   \
armada-7040-db.dtb  \
armada-7040-db-nand.dtb \
armada-8040-db.dtb  \
diff --git a/arch/arm/dts/armada-385-amc.dts 
b/arch/arm/dts/armada-385-db-88f6820-amc.dts
similarity index 100%
rename from arch/arm/dts/armada-385-amc.dts
rename to arch/arm/dts/armada-385-db-88f6820-amc.dts
diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_defconfig
index 319d9dbd9c3f..1f983af1b648 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_defconfig
@@ -41,7 +41,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_EFI_PARTITION=y
 # CONFIG_PARTITION_UUIDS is not set
 # CONFIG_SPL_PARTITION_UUIDS is not set
-CONFIG_DEFAULT_DEVICE_TREE="armada-385-amc"
+CONFIG_DEFAULT_DEVICE_TREE="armada-385-db-88f6820-amc"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_BLK=y
-- 
2.21.0

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

Re: [U-Boot] Clearfog Base PCI-E not working

2019-03-16 Thread Chris Packham 
On Sat, Mar 16, 2019 at 8:07 PM Chris Packham  wrote:
>
> On Fri, Mar 15, 2019 at 6:56 PM Stefan Roese  wrote:
> >
> > On 14.03.19 17:37, Влад Мао wrote:
> > > I found mismatched entries in DTS:
> > >
> > > In armada-388-clearfog.dts:
> > >
> > >  pcie-controller {
> > >  status = "okay";
> > >
> > > But in armada-385.dtsi we have:
> > >
> > >  pciec: pcie {
> > >  compatible = "marvell,armada-370-pcie";
> > >
> > > After fixing it, PCIE does show up as expected.
> >
> > Thanks for spotting this. Could you please send a proper patch to
> > fix this to the list?
> >
>
> These other boards seem similarly affected.
>
> armada-385-turris-omnia.dts
> armada-388-gp.dts
> armada-385-amc.dts
> armada-38x-controlcenterdc.dts
>
> I think I must have missed them when I did the last sync with Linux.

I've sent a patch for the armada-38x boards. It also appears that the
armada-xp boards have a similar problem (unrelated to my syncing).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: mvebu: use correct name for pcie controller

2019-03-16 Thread Chris Packham 
When armada-385.dtsi was sync'd from Linux the name of the node
describing the pcie controller was changed from pcie-controller to pcie.
Some of the boards that include armada-385.dtsi were missed in the
update retaining the old name. This updates the affected boards.

Reported-by: Влад Мао 
Signed-off-by: Chris Packham 
---

 arch/arm/dts/armada-385-amc.dts | 2 +-
 arch/arm/dts/armada-385-turris-omnia.dts| 2 +-
 arch/arm/dts/armada-388-clearfog.dts| 2 +-
 arch/arm/dts/armada-388-gp.dts  | 2 +-
 arch/arm/dts/armada-38x-controlcenterdc.dts | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/armada-385-amc.dts b/arch/arm/dts/armada-385-amc.dts
index d4d127fa024b..c9ccbb57fff5 100644
--- a/arch/arm/dts/armada-385-amc.dts
+++ b/arch/arm/dts/armada-385-amc.dts
@@ -133,7 +133,7 @@
};
};
 
-   pcie-controller {
+   pcie {
status = "okay";
pcie@1,0 {
/* Port 0, Lane 0 */
diff --git a/arch/arm/dts/armada-385-turris-omnia.dts 
b/arch/arm/dts/armada-385-turris-omnia.dts
index 28eede180e4f..5511c84849ee 100644
--- a/arch/arm/dts/armada-385-turris-omnia.dts
+++ b/arch/arm/dts/armada-385-turris-omnia.dts
@@ -96,7 +96,7 @@
};
};
 
-   pcie-controller {
+   pcie {
status = "okay";
 
pcie@1,0 {
diff --git a/arch/arm/dts/armada-388-clearfog.dts 
b/arch/arm/dts/armada-388-clearfog.dts
index a3493ddd4d45..4ddeaa02f122 100644
--- a/arch/arm/dts/armada-388-clearfog.dts
+++ b/arch/arm/dts/armada-388-clearfog.dts
@@ -124,7 +124,7 @@
};
};
 
-   pcie-controller {
+   pcie {
status = "okay";
/*
 * The two PCIe units are accessible through
diff --git a/arch/arm/dts/armada-388-gp.dts b/arch/arm/dts/armada-388-gp.dts
index 7bc878f5a926..d5ad2fd7e221 100644
--- a/arch/arm/dts/armada-388-gp.dts
+++ b/arch/arm/dts/armada-388-gp.dts
@@ -234,7 +234,7 @@
};
};
 
-   pcie-controller {
+   pcie {
status = "okay";
/*
 * One PCIe units is accessible through
diff --git a/arch/arm/dts/armada-38x-controlcenterdc.dts 
b/arch/arm/dts/armada-38x-controlcenterdc.dts
index ffbd0dcaae47..bad7c60f19c4 100644
--- a/arch/arm/dts/armada-38x-controlcenterdc.dts
+++ b/arch/arm/dts/armada-38x-controlcenterdc.dts
@@ -243,7 +243,7 @@
};
};
 
-   pcie-controller {
+   pcie {
status = "okay";
/*
 * The two PCIe units are accessible through
-- 
2.21.0

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

Re: [U-Boot] Clearfog Base PCI-E not working

2019-03-16 Thread Chris Packham 
On Fri, Mar 15, 2019 at 6:56 PM Stefan Roese  wrote:
>
> On 14.03.19 17:37, Влад Мао wrote:
> > I found mismatched entries in DTS:
> >
> > In armada-388-clearfog.dts:
> >
> >  pcie-controller {
> >  status = "okay";
> >
> > But in armada-385.dtsi we have:
> >
> >  pciec: pcie {
> >  compatible = "marvell,armada-370-pcie";
> >
> > After fixing it, PCIE does show up as expected.
>
> Thanks for spotting this. Could you please send a proper patch to
> fix this to the list?
>

These other boards seem similarly affected.

armada-385-turris-omnia.dts
armada-388-gp.dts
armada-385-amc.dts
armada-38x-controlcenterdc.dts

I think I must have missed them when I did the last sync with Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot