[U-Boot] [PATCH] kbuild: fix parallel build race caused by u-boot.cfg regeneration

[Masahiro Yamada]

Multiple people have reported intermittent build failure in parallel
building.

Kever Yang reported this issue some time ago [1], but I could not
get enough clue at that time.

This time, Richard Purdie provided a complete build log [2], which
was very helpful for me to root-cause it.

The cause of the problem is commit 0d982c585330 ("Makefile: add
dependencies to regenerate u-boot.cfg when lost").

That commit added the 'cfg' as the prerequisite of the 'all' target,
so the parallel build tries to run it simultaneously, then regenerates
a symlink while building objects.

When u-boot.cfg is accidentally lost, lets' rebuild it before
descending into any subdirectories.

Also, what is annoying is u-boot.cfg is currently regenerated every
time since it depends on FORCE. We can get rid of all the prerequisites
of u-boot.cfg because u-boot.cfg is rebuilt anyway as the byproduct of
auto.conf when a user updates the .config file.

[1] https://lists.denx.de/pipermail/u-boot/2018-June/330341.html
[2] 
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/160/steps/7/logs/step1b

Fixes: 0d982c585330 ("Makefile: add dependencies to regenerate u-boot.cfg when 
lost")
Reported-by: Kever Yang 
Reported-by: Richard Purdie 
Signed-off-by: Masahiro Yamada 
---

 Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index eeb299f..363ebc8 100644
--- a/Makefile
+++ b/Makefile
@@ -534,7 +534,7 @@ include/config/%.conf: $(KCONFIG_CONFIG) 
include/config/auto.conf.cmd
@# Otherwise, 'make silentoldconfig' would be invoked twice.
$(Q)touch include/config/auto.conf
 
-u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg: include/config.h FORCE
+u-boot.cfg spl/u-boot.cfg tpl/u-boot.cfg:
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.autoconf $(@)
 
 -include include/autoconf.mk
@@ -910,7 +910,7 @@ quiet_cmd_cfgcheck = CFGCHK  $2
 cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
$(srctree)/scripts/config_whitelist.txt $(srctree)
 
-all:   $(ALL-y) cfg
+all:   $(ALL-y)
 ifeq ($(CONFIG_DM_I2C_COMPAT)$(CONFIG_SANDBOX),y)
@echo >&2 "= WARNING =="
@echo >&2 "This board uses CONFIG_DM_I2C_COMPAT. Please remove"
@@ -1549,7 +1549,7 @@ prepare0: archprepare FORCE
$(Q)$(MAKE) $(build)=.
 
 # All the preparing..
-prepare: prepare0
+prepare: prepare0 cfg
 
 # Generate some files
 # ---
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] usb: xhci-mem: Fix scratchpad array issue

[Bin Meng]

On Tue, Jan 8, 2019 at 7:19 PM Marek Vasut  wrote:
>
> On 1/8/19 7:34 AM, Bin Meng wrote:
> > On Tue, Jan 8, 2019 at 12:00 PM Ye Li  wrote:
> >>
> >> On 1/7/2019 5:54 PM, Bin Meng wrote:
> >>> On Mon, Jan 7, 2019 at 10:45 AM Ye Li  wrote:
> 
>  After updating the value of dev_context_ptrs[0], we should flush this
>  from cache to memory. Otherwise the xhci controller won't use it.
> 
>  Signed-off-by: Ye Li 
>  Reviewed-by: Marek Vasut 
>  ---
>  Changes for v2:
> - Change to use sizeof(ctrl->dcbaa->dev_context_ptrs[0])
> 
>   drivers/usb/host/xhci-mem.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> >>>
> >>> Reviewed-by: Bin Meng 
> >>>
> >>> But you need do the same in xhci_scratchpad_free() too. Please fix it in 
> >>> v3.
> >>>
> >> The xhci controller has been stopped before calling xhci_scratchpad_free, 
> >> is it necessary to
> >> add flush in this function? And I don't see other buffers are flushed when 
> >> freeing.
> >>
> >
> > Ah, yes. It's called after HCD reset, so that's not needed.
>
> Shall I pick this for this release then, Bin ?
>

Yes, I think so.

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

Re: [U-Boot] [U-Boot, 2/2] mmc: bring back partition init for non-DM MMC drivers

[Tom Rini]

On Mon, Dec 17, 2018 at 10:05:45AM +, Andre Przywara wrote:

> Commit d0851c893706 ("blk: Call part_init() in the post_probe() method")
> removed the call to part_init() in mmc.c, as this is done by the DM_MMC
> framework.
> However Allwinner is (still) relying on a non-DM MMC driver, so we are
> now missing the implicit partition init, leading to failing MMC accesses
> due to the missing partition information.
> 
> Bring the call back just for non-DM MMC driver to fix this regression.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Simon Glass 
> Tested-by: Soeren Moch 
> ---
>  drivers/mmc/mmc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index f5c821e308..d858127132 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2449,6 +2449,10 @@ static int mmc_startup(struct mmc *mmc)
>   bdesc->revision[0] = 0;
>  #endif
>  
> +#if !defined(CONFIG_DM_MMC) && (!defined(CONFIG_SPL_BUILD) || 
> defined(CONFIG_SPL_LIBDISK_SUPPORT))
> + part_init(bdesc);
> +#endif
> +
>   return 0;
>  }

So, this pushes pine_h64 over the limit:
https://travis-ci.org/trini/u-boot/jobs/477078336

-- 
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] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 9:52 PM, Simon Goldschmidt wrote:
> Am 08.01.2019 um 16:01 schrieb Simon Goldschmidt:
>> Am 08.01.2019 um 15:50 schrieb Marek Vasut:
>>> On 1/8/19 3:48 PM, Tom Rini wrote:
 On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
>> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
>>>
>>> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
 On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>
> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut 
>> wrote:
>>>
>>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
 In order to build a smaller SPL, let's imply SPL_DM_RESET and
 SPL_WATCHDOG_SUPPORT instead of selecting them, so they can
 be disabled
 via defconfig.

 This also seems to be required to use OF_PLATDATA, as the
 reset drivers
 don't seem to work with it.
>>>
>>> How do you un-reset IP blocks if you disable the reset
>>> controller ?
>>
>> Here again, socfpga seems to be another bad example. Taking
>> peripherals out of reset
>> is cluttered throughout the mach-socfpga code at least in SPL.
>> By now
>> I know socfpga is
>> lacking support for clock and reset management via devicetree.
>> And
>> this is bad, I know,
>> but can we keep this a seperate issue from OF_PLATDATA?
>>
>> That being said, drivers/reset/reset-uclass.c fails to compile
>> with
>> OF_PLATDATA, so I
>> guess this has not been used with OF_PLATDATA before. And
>> given that I
>> don't seem
>> to need it for socfpga either, I don't think this would be the
>> right
>> series to fix that.
>
> Don't you need it to unreset at least the DWMMC or CQSPI ?

 Reading the code, it seems like that's taken care of through
 another hack in
 spl_boot_device() ;-)
>>>
>>> Sigh.
>>>
> Anyway, I'd much prefer to start cleaning up the horrorshow that
> arch/arm/mach-socfpga is in terms of clock and reset, at least
> like A10.
> Would that be possible ?

 I would be best, yes. I don't know when I will find the time to
 do that, though.
 I don't know how much effort that would be, either. Is there
 maybe a patch
 where A10 got converted from "as bad as gen5" to its current
 state? That
 would help me to see if I can do it...
>>>
>>> A10 got switched to reset framework recently (in last 6 months or
>>> so),
>>> the reset driver is the same for Gen5 and A10 too, so it should
>>> be easy
>>> to recycle.
>>
>> Hmm, ok, let me check that... it would indeed be nice to port this
>> to gen5.
>>
>> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
>> to continue on this? I mean, I thought I heard people here saying
>> "use
>> OF_PLATDATA" if you're running out of space in SPL. After using
>> it, I'm not too
>> keen on using it, either, but it does seem to give me some code
>> space back...
>
> OF_PLATDATA is for platforms with really small SRAM, some 30k or
> below.
> This platform has a massive 60k of SRAM for SPL, so if we're
> running out
> of space, we're doing something wrong.

 It's not for "30k or below" but "needs more space to enable all desired
 features inside of SPL".
>>>
>>> Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
>>> bloated that even platform with so much space has issues, how can we
>>> even cater for the rest of platforms with much more limited SPL ? And if
>>> that is the case, we have a much bigger problem ...
>>
>> I have to add here: I'm not running out of space in SPL just yet. I'm at
>> 45k But I have tried and the remaining 15k don't seem to be enough to
>> add verified FIT loading code. I expect this to be something very rarely
>> used, if it is used at all (I saw presentations doing this to implement
>> verified boot, but I failed to find the code in SPL that does this)...
>>
>> I don't know yet how I'll continue here. I'll check again exactly how
>> much of the SRAM my current OF_PLATDATA patches save.
> 
> Ok, so when booting from mmc (with the tiny mmc framework), this series
> saves ~5.6 KiB of the SRAM for SPL (~3.7 KiB .text reduction, ~1.7 KiB
> for the DTB binary, other sections are slightly smaller).
> 
> It's not the world, but it's more than 10% (from ~40 KiB to 34.5 KiB).
> I don't insist on doing this, but I wanted to write down numbers in case
> someone wants to discuss this further.

I'm sure if you went all the way and removed even the DT support
altogether, the SPL would 

Re: [U-Boot] [PATCH] Fix typo: missmatched -> mismatched.

[Peng Fan]

> -Original Message-
> From: Vagrant Cascadian [mailto:vagr...@debian.org]
> Sent: 2019年1月9日 5:10
> To: u-boot@lists.denx.de
> Cc: Vagrant Cascadian ; Peng Fan
> ; Fabio Estevam 
> Subject: [PATCH] Fix typo: missmatched -> mismatched.
> 
> Signed-off-by: Vagrant Cascadian 
> ---
> 
>  tools/imx8image.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/imx8image.c b/tools/imx8image.c index
> 6e8ac464e7..d93de733ab 100644
> --- a/tools/imx8image.c
> +++ b/tools/imx8image.c
> @@ -674,7 +674,7 @@ static int get_container_image_start_pos(image_t
> *image_stack, uint32_t align)
>   fclose(fd);
> 
>   if (header.tag != IVT_HEADER_TAG_B0) {
> - fprintf(stderr, "header tag missmatched \n");
> + fprintf(stderr, "header tag mismatched \n");
>   exit(EXIT_FAILURE);
>   } else {
>   file_off +=

Reviewed-by: Peng Fan 

> --
> 2.20.1

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

Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time

[AKASHI Takahiro]

Heinrich,

Do you have any further comments here?
Otherwise, I'd like to send out v3 shortly.

-Takahiro Akashi

On Thu, Dec 13, 2018 at 04:58:29PM +0900, AKASHI Takahiro wrote:
> Heinrich,
> 
> On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt wrote:
> > On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
> > > Currently, efi_init_obj_list() scan disk devices only once, and never
> > > change a list of efi disk devices. This will possibly result in failing
> > > to find a removable storage which may be added later on. See [1].
> > > 
> > > In this patch, called is efi_disk_update() which is responsible for
> > > re-scanning UCLASS_BLK devices and removing/adding efi disks if necessary.
> > > 
> > > For example,
> > > 
> > > => efishell devices
> > > Scanning disk pci_mmc.blk...
> > > Found 3 disks
> > > Device Name
> > > 
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > > => usb start
> > > starting USB...
> > > USB0:   USB EHCI 1.00
> > > scanning bus 0 for devices... 3 USB Device(s) found
> > >scanning usb for storage devices... 1 Storage Device(s) found
> > > => efishell devices
> > > Scanning disk usb_mass_storage.lun0...
> > > Device Name
> > > 
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> > > 
> > > Without this patch, the last device, USB mass storage, won't show up.
> > > 
> > > [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> > > 
> > > Signed-off-by: AKASHI Takahiro 
> > 
> > Why should we try to fix something in the EFI subsystems that goes wrong
> > in the handling of device enumeration.
> 
> No.
> This is a natural result from how efi disks are currently implemented on 
> u-boot.
> Do you want to totally re-write/re-implement efi disks?
> 
> Furthermore, your comment here doesn't match your previous comment[1].
> 
> [1] https://lists.denx.de/pipermail/u-boot/2018-November/346860.html
> 
> -Takahiro Akashi
> 
> > @Marek
> > Why should a 'usb start' command be needed to make a plugged in device
> > available?
> > 
> > Best regards
> > 
> > Heirnich
> > 
> > 
> > 
> > > ---
> > >  cmd/bootefi.c |  17 +++-
> > >  include/efi_loader.h  |   4 +
> > >  lib/efi_loader/efi_disk.c | 191 ++
> > >  3 files changed, 210 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > > index 3cefb4d0ecaa..82649e211fda 100644
> > > --- a/cmd/bootefi.c
> > > +++ b/cmd/bootefi.c
> > > @@ -56,9 +56,22 @@ efi_status_t efi_init_obj_list(void)
> > >*/
> > >   efi_save_gd();
> > >  
> > > - /* Initialize once only */
> > > - if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
> > > + if (efi_obj_list_initialized == EFI_SUCCESS) {
> > > +#ifdef CONFIG_PARTITIONS
> > > + ret = efi_disk_update();
> > > + if (ret != EFI_SUCCESS)
> > > + printf("+++ updating disks list failed\n");
> > > +
> > > + /*
> > > +  * It may sound odd, but most part of EFI should
> > > +  * yet work.
> > > +  */
> > > +#endif
> > >   return efi_obj_list_initialized;
> > > + } else if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) {
> > > + /* Initialize once only */
> > > + return efi_obj_list_initialized;
> > > + }
> > >  
> > >   /* Initialize system table */
> > >   ret = efi_initialize_system_table();
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index 5cc3bded03fa..3bae1844befb 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -260,6 +260,10 @@ efi_status_t efi_initialize_system_table(void);
> > >  efi_status_t efi_console_register(void);
> > >  /* Called by bootefi to make all disk storage accessible as EFI objects 
> > > */
> > >  efi_status_t efi_disk_register(void);
> > > +/* Check validity of efi disk */
> > > +bool efi_disk_is_valid(efi_handle_t handle);
> > > +/* Called by bootefi to find and update disk storage information */
> > > +efi_status_t efi_disk_update(void);
> > >  /* Create handles and protocols for the partitions of a block device */
> > >  int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc 
> > > *desc,
> > >  const char *if_typename, int diskid,
> > > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > > index c037526ad2d0..0c4d79ee3fc9 100644
> > > --- a/lib/efi_loader/efi_disk.c
> > > +++ b/lib/efi_loader/efi_disk.c
> > > @@ -14,10 +14,14 @@
> > >  

Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation

[Lukasz Majewski]

Hi Alex,

> On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski  wrote:
> >
> > Hi Alex,
> >  
> > > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini 
> > > wrote:  
> > > >
> > > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote:
> > > >  
> > > > > This commit prevents from re-configuring pins if those were
> > > > > configured before relocation.
> > > > >
> > > > > Some pins - like UART or DDR must be setup before relocation
> > > > > (as they have 'u-boot,dm-pre-reloc' property set in DTS).
> > > > > Without this change, those pins are re-configured after
> > > > > relocation (pre_reloc_only = 0, so we do not "continue").
> > > > > Such behavior may be a problem for DDR PAD configuration, as
> > > > > they might be already leveled/tuned with original setup).
> > > > >
> > > > > Signed-off-by: Lukasz Majewski   
> > > >
> > > > Applied to u-boot/master, thanks!
> > > >  
> > >
> > > I've bisected out to this commit and it's slightly broken things
> > > for me on an AM3352. It all works fine so long as I boot MLO from
> > > MMC (so the MMC is probed, pinctrl setup), but if I boot from
> > > UART then I get to full U-Boot, MMC hasn't been probed and the
> > > pinmuxing isn't set up for the MMC.  
> >
> > I suppose that the pinmux node have set "u-boot,dm-pre-reloc"
> > property?
> >  
> 
> Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess
> that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL.

I do need to check this -> as in my case I do have
"u-boot,dm-pre-reloc" property. And yes, in my case I do not have TPL
too (just SPL).

> 
> > The problem is not with lack of eMMC probing - it is with pinctrl
> > nodes having "u-boot,dm-pre-reloc" set in DTS and the eMMC is
> > probed after MLO/SPL.
> > It looks like your use case implicitly depends on pinmux being
> > reconfigured no matter if we are pre-relocated (MLO) or afterwards.
> >  
> 
> Yes, that's a much clearer description...

Frankly, your mail opened my eyes to a use case which was handled (I
assume on purpose) with the old code - the "cross" boot with pinmux
and devices.

For example boot from UART (MLO/SPL) and then continue with eMMC (which
require pinmux).

> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpJuoEt05lBT.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation

[Alex Kiernan]

On Tue, Jan 8, 2019 at 10:52 PM Lukasz Majewski  wrote:
>
> Hi Alex,
>
> > On Thu, Dec 27, 2018 at 3:49 PM Tom Rini  wrote:
> > >
> > > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote:
> > >
> > > > This commit prevents from re-configuring pins if those were
> > > > configured before relocation.
> > > >
> > > > Some pins - like UART or DDR must be setup before relocation
> > > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without
> > > > this change, those pins are re-configured after relocation
> > > > (pre_reloc_only = 0, so we do not "continue").
> > > > Such behavior may be a problem for DDR PAD configuration, as they
> > > > might be already leveled/tuned with original setup).
> > > >
> > > > Signed-off-by: Lukasz Majewski 
> > >
> > > Applied to u-boot/master, thanks!
> > >
> >
> > I've bisected out to this commit and it's slightly broken things for
> > me on an AM3352. It all works fine so long as I boot MLO from MMC (so
> > the MMC is probed, pinctrl setup), but if I boot from UART then I get
> > to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up
> > for the MMC.
>
> I suppose that the pinmux node have set "u-boot,dm-pre-reloc"
> property?
>

Yeah, well "u-boot,dm-spl", though now I re-read the docs I guess
that's equivalent to "u-boot,dm-pre-reloc" as I've no TPL.

> The problem is not with lack of eMMC probing - it is with pinctrl nodes
> having "u-boot,dm-pre-reloc" set in DTS and the eMMC is probed after
> MLO/SPL.
> It looks like your use case implicitly depends on pinmux being
> reconfigured no matter if we are pre-relocated (MLO) or afterwards.
>

Yes, that's a much clearer description...

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

Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation

[Lukasz Majewski]

Hi Alex,

> On Thu, Dec 27, 2018 at 3:49 PM Tom Rini  wrote:
> >
> > On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote:
> >  
> > > This commit prevents from re-configuring pins if those were
> > > configured before relocation.
> > >
> > > Some pins - like UART or DDR must be setup before relocation
> > > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without
> > > this change, those pins are re-configured after relocation
> > > (pre_reloc_only = 0, so we do not "continue").
> > > Such behavior may be a problem for DDR PAD configuration, as they
> > > might be already leveled/tuned with original setup).
> > >
> > > Signed-off-by: Lukasz Majewski   
> >
> > Applied to u-boot/master, thanks!
> >  
> 
> I've bisected out to this commit and it's slightly broken things for
> me on an AM3352. It all works fine so long as I boot MLO from MMC (so
> the MMC is probed, pinctrl setup), but if I boot from UART then I get
> to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up
> for the MMC.

I suppose that the pinmux node have set "u-boot,dm-pre-reloc"
property?

The problem is not with lack of eMMC probing - it is with pinctrl nodes
having "u-boot,dm-pre-reloc" set in DTS and the eMMC is probed after
MLO/SPL.
It looks like your use case implicitly depends on pinmux being
reconfigured no matter if we are pre-relocated (MLO) or afterwards.

As stated in the commit message above - for DDR pads it is dangerous to
re-configure them.

I'm wondering as in the device_probe() @ drivers/core/device.c the
DM_FLAG_ACTIVATED is checked. This should be enough to prevent
re-checking (of the DDR pins).

Anyway, this will not fix the issue you mentioned. 

I've put Simon to CC, maybe he would have some input?


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpoSIKz9q2rj.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Fix typo: missmatched -> mismatched.

[Vagrant Cascadian]

Signed-off-by: Vagrant Cascadian 
---

 tools/imx8image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/imx8image.c b/tools/imx8image.c
index 6e8ac464e7..d93de733ab 100644
--- a/tools/imx8image.c
+++ b/tools/imx8image.c
@@ -674,7 +674,7 @@ static int get_container_image_start_pos(image_t 
*image_stack, uint32_t align)
fclose(fd);
 
if (header.tag != IVT_HEADER_TAG_B0) {
-   fprintf(stderr, "header tag missmatched \n");
+   fprintf(stderr, "header tag mismatched \n");
exit(EXIT_FAILURE);
} else {
file_off +=
-- 
2.20.1

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

Am 08.01.2019 um 16:01 schrieb Simon Goldschmidt:

Am 08.01.2019 um 15:50 schrieb Marek Vasut:

On 1/8/19 3:48 PM, Tom Rini wrote:

On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:

On 1/8/19 1:46 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:


On 1/8/19 1:09 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:


On 1/8/19 7:24 AM, Simon Goldschmidt wrote:

On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:


On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


Here again, socfpga seems to be another bad example. Taking
peripherals out of reset
is cluttered throughout the mach-socfpga code at least in SPL. By now
I know socfpga is
lacking support for clock and reset management via devicetree. And
this is bad, I know,
but can we keep this a seperate issue from OF_PLATDATA?

That being said, drivers/reset/reset-uclass.c fails to compile with
OF_PLATDATA, so I
guess this has not been used with OF_PLATDATA before. And given that I
don't seem
to need it for socfpga either, I don't think this would be the right
series to fix that.


Don't you need it to unreset at least the DWMMC or CQSPI ?


Reading the code, it seems like that's taken care of through another hack in
spl_boot_device() ;-)


Sigh.


Anyway, I'd much prefer to start cleaning up the horrorshow that
arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
Would that be possible ?


I would be best, yes. I don't know when I will find the time to do that, though.
I don't know how much effort that would be, either. Is there maybe a patch
where A10 got converted from "as bad as gen5" to its current state? That
would help me to see if I can do it...


A10 got switched to reset framework recently (in last 6 months or so),
the reset driver is the same for Gen5 and A10 too, so it should be easy
to recycle.


Hmm, ok, let me check that... it would indeed be nice to port this to gen5.

Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
to continue on this? I mean, I thought I heard people here saying "use
OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
keen on using it, either, but it does seem to give me some code space back...


OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
This platform has a massive 60k of SRAM for SPL, so if we're running out
of space, we're doing something wrong.


It's not for "30k or below" but "needs more space to enable all desired
features inside of SPL".


Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
bloated that even platform with so much space has issues, how can we
even cater for the rest of platforms with much more limited SPL ? And if
that is the case, we have a much bigger problem ...


I have to add here: I'm not running out of space in SPL just yet. I'm at
45k But I have tried and the remaining 15k don't seem to be enough to
add verified FIT loading code. I expect this to be something very rarely
used, if it is used at all (I saw presentations doing this to implement
verified boot, but I failed to find the code in SPL that does this)...

I don't know yet how I'll continue here. I'll check again exactly how
much of the SRAM my current OF_PLATDATA patches save.


Ok, so when booting from mmc (with the tiny mmc framework), this series 
saves ~5.6 KiB of the SRAM for SPL (~3.7 KiB .text reduction, ~1.7 KiB 
for the DTB binary, other sections are slightly smaller).


It's not the world, but it's more than 10% (from ~40 KiB to 34.5 KiB).
I don't insist on doing this, but I wanted to write down numbers in case 
someone wants to discuss this further.


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

[U-Boot] common/board_f.c: init_sequence_f_r used for which arches?

[Robert P. J. Day]

  just noticed in common/board_f.c the inconsistency:

#if defined(CONFIG_X86) || defined(CONFIG_ARC)
/*
 * For now this code is only used on x86.

 ... snip ...

 * NOTE: At present only x86 uses this route, but it is intended that
 * all archs will move to this when generic relocation is implemented.
 */

so should the comment be changed to refer to both x86 and arc, or is
there a long-term plan for all archs, or what?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
  http://crashcourse.ca/dokuwiki

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support

[Jagan Teki]

On Tue, Jan 8, 2019 at 5:09 PM Andre Przywara  wrote:
>
> On Tue, 8 Jan 2019 16:27:14 +0530
> Jagan Teki  wrote:
>
> Hi,
>
> > On Mon, Jan 7, 2019 at 6:35 AM André Przywara
> >  wrote:
> > >
> > > On 31/12/2018 16:59, Jagan Teki wrote:
> > > > Clock control unit comprises of parent clocks, gates,
> > > > multiplexers, dividers, multipliers, pre/post dividers and flags
> > > > etc.
> > > >
> > > > So, the U-Boot implementation of ccu has divided into gates and
> > > > tree. gates are generic clock configuration of enable/disable bit
> > > > management which can be handle via ccu_clock_gate.
> > >
> > > So if I understand this correctly, you implement the gate
> > > functionality separately from the complex clock code, even if they
> > > are the same clock from the DT point of view? So if one wants to
> > > enable the MMC0 clock, which is a mux/divider clock, one needs to
> > > specify an extra entry in the gate array to describe the enable bit
> > > in this special clock register? Sounds a bit surprising, but is
> > > probably a neat trick to keep things simple. There should be a
> > > comment in the code to this regard then.
> >
> > Exactly. Idea is to keep the macro's as simple as possible.
> >
> > Adding gates clocks separately make easy and reasonable way to
> > enable/disable clock operations. We even operate with single macro
> > with all clock attributes along with gate(either another member or
> > common structure like Linux does), but that seems not simple as per as
> > my experince since there are many IP's like USB's just need
> > enable/disable.
> >
> > >
> > > > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm,
> > > > nkmp, pre/post div, flags etc. which were managed via
> > > > ccu_clock_tree.
> > >
> > > For a start, can we use more descriptive names than those very
> > > specific MP/NK names? DIV_MUX and PLL sound more descriptive to me.
> > > I understand that Linux uses those terms, but it would be great if
> > > uninitiated people have a chance to understand this as well.
> > >
> > > > This patch add support for MP, NK, MISC, FIXED clock types as
> > > > part of ccu clock tree with get_rate functionality this
> > > > eventually used by uart driver. and rest of the infrastructure
> > > > will try to add while CLK is being used on respective peripherals.
> > > >
> > > > Note that few of the tree type clock would require to enable
> > > > gates on their specific clock, in that case we need to add the
> > > > gate details via ccu_clock_gate, example: MP with gate so the
> > > > gate offset, bit value should add as part of ccu_clock_gate.
> > > >
> > > > Signed-off-by: Jagan Teki 
> > > > ---
> > > >  arch/arm/include/asm/arch-sunxi/ccu.h | 192
> > > > +- drivers/clk/sunxi/clk_a64.c
> > > > |  40 ++ drivers/clk/sunxi/clk_sunxi.c | 182
> > > >  3 files changed, 413 insertions(+), 1
> > > > deletion(-)
> > > >
> > > > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h
> > > > b/arch/arm/include/asm/arch-sunxi/ccu.h index
> > > > 3fdc26978d..61b8c36b3b 100644 ---
> > > > a/arch/arm/include/asm/arch-sunxi/ccu.h +++
> > > > b/arch/arm/include/asm/arch-sunxi/ccu.h @@ -7,15 +7,204 @@
> > > >  #ifndef _ASM_ARCH_CCU_H
> > > >  #define _ASM_ARCH_CCU_H
> > > >
> > > > +#define OSC_32K_ULL  32000ULL
> > >
> > > 32768
> > >
> > > And why ULL? The whole Allwinner clock system works with 32-bit
> > > values, so just U would be totally sufficient. This avoid blowing
> > > this up to 64 bit unnecessarily, which sounds painful for those
> > > poor ARMv7 parts.
> > > > +#define OSC_24M_ULL  2400ULL
> > > > +
> > > > +/**
> > > > + * enum ccu_clk_type - ccu clock types
> > > > + *
> > > > + * @CCU_CLK_TYPE_MISC:   misc clock type
> > >
> > > What is MISC, exactly? Seems like an artefact clock to me, some
> > > placeholder you need because gate clocks are handled separately in
> > > the gates struct. Should this be called something with SIMPLE
> > > instead, or GATE?
> >
> > Unlike MP type in MMC, UART doesn't need any clock attributes like
> > dividers, mux, etc, just have attached parent. I don't think UART
> > clock is simple one It has parent, that indeed have another parents
> > and so...on, ie reason I named as MISC.
>
> Not really, as far as I can see the UART clock is a just a gate clock as
> many others, with one parent (APB2).
> The fact that APB2 in turn can have multiple parents doesn't affect the
> UART clock itself, as you model this via the clock tree.
>
> In fact we could have similar clocks in the tree structure for the
> other gate clocks (USB, for instance), it's just that the UART is the
> only user so far which actually queries the clock rate.
>
> So MISC is way too generic, I would still prefer CCU_CLK_TYPE_GATE.

TYPE_GATE is more sense. fine for me.

>
> > > > + * @CCU_CLK_TYPE_FIXED:  fixed clock type
> > > > + * @CCU_CLK_TYPE_MP: mp clock 

[U-Boot] [PATCH v5.1 01/26] clk: Add Allwinner A64 CLK driver

[Jagan Teki]

Add initial clock driver for Allwinner A64.

Implement USB clock enable and disable functions for
OHCI, EHCI, OTG and USBPHY gate and clock registers
via ccu clk gate table.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
Changes for v5.1:
- s/CCU_CLK_F_INIT_DONE/CCU_CLK_F_IS_VALID
- Use ccu_flags instead of ccu_clk_flags since reset flags is included

 arch/arm/include/asm/arch-sunxi/ccu.h | 65 +++
 drivers/clk/Kconfig   |  1 +
 drivers/clk/Makefile  |  1 +
 drivers/clk/sunxi/Kconfig | 18 +++
 drivers/clk/sunxi/Makefile|  9 
 drivers/clk/sunxi/clk_a64.c   | 46 +
 drivers/clk/sunxi/clk_sunxi.c | 74 +++
 7 files changed, 214 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/ccu.h
 create mode 100644 drivers/clk/sunxi/Kconfig
 create mode 100644 drivers/clk/sunxi/Makefile
 create mode 100644 drivers/clk/sunxi/clk_a64.c
 create mode 100644 drivers/clk/sunxi/clk_sunxi.c

diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h 
b/arch/arm/include/asm/arch-sunxi/ccu.h
new file mode 100644
index 00..24efe0ab0a
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/ccu.h
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#ifndef _ASM_ARCH_CCU_H
+#define _ASM_ARCH_CCU_H
+
+/**
+ * enum ccu_flags - ccu clock flags
+ *
+ * @CCU_CLK_F_IS_VALID:is given clock gate is valid?
+ */
+enum ccu_flags {
+   CCU_CLK_F_IS_VALID  = BIT(0),
+};
+
+/**
+ * struct ccu_clk_gate - ccu clock gate
+ * @off:   gate offset
+ * @bit:   gate bit
+ * @flags: ccu clock gate flags
+ */
+struct ccu_clk_gate {
+   u16 off;
+   u32 bit;
+   enum ccu_flags flags;
+};
+
+#define GATE(_off, _bit) { \
+   .off = _off,\
+   .bit = _bit,\
+   .flags = CCU_CLK_F_IS_VALID,\
+}
+
+/**
+ * struct ccu_desc - clock control unit descriptor
+ *
+ * @gates: clock gates
+ */
+struct ccu_desc {
+   const struct ccu_clk_gate *gates;
+};
+
+/**
+ * struct ccu_priv - sunxi clock control unit
+ *
+ * @base:  base address
+ * @desc:  ccu descriptor
+ */
+struct ccu_priv {
+   void *base;
+   const struct ccu_desc *desc;
+};
+
+/**
+ * sunxi_clk_probe - common sunxi clock probe
+ * @dev:   clock device
+ */
+int sunxi_clk_probe(struct udevice *dev);
+
+extern struct clk_ops sunxi_clk_ops;
+
+#endif /* _ASM_ARCH_CCU_H */
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index eadf7f8250..51c931b906 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -104,6 +104,7 @@ source "drivers/clk/imx/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/owl/Kconfig"
 source "drivers/clk/renesas/Kconfig"
+source "drivers/clk/sunxi/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9acbb1a650..6a4ff9143b 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
 obj-$(CONFIG_CLK_RENESAS) += renesas/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
 obj-$(CONFIG_CLK_STM32F) += clk_stm32f.o
 obj-$(CONFIG_CLK_STM32MP1) += clk_stm32mp1.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
new file mode 100644
index 00..bf5ecb3801
--- /dev/null
+++ b/drivers/clk/sunxi/Kconfig
@@ -0,0 +1,18 @@
+config CLK_SUNXI
+   bool "Clock support for Allwinner SoCs"
+   depends on CLK && ARCH_SUNXI
+   default y
+   help
+ This enables support for common clock driver API on Allwinner
+ SoCs.
+
+if CLK_SUNXI
+
+config CLK_SUN50I_A64
+   bool "Clock driver for Allwinner A64"
+   default MACH_SUN50I
+   help
+ This enables common clock driver support for platforms based
+ on Allwinner A64 SoC.
+
+endif # CLK_SUNXI
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
new file mode 100644
index 00..fb20d28333
--- /dev/null
+++ b/drivers/clk/sunxi/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2018 Amarula Solutions.
+#
+# SPDX-License-Identifier:  GPL-2.0+
+#
+
+obj-$(CONFIG_CLK_SUNXI) += clk_sunxi.o
+
+obj-$(CONFIG_CLK_SUN50I_A64) += clk_a64.o
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
new file mode 100644
index 00..803a2f711d
--- /dev/null
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Amarula Solutions.
+ * Author: Jagan Teki 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct ccu_clk_gate a64_gates[] = {
+   [CLK_BUS_OTG]   = 

[U-Boot] [PATCH v5.1 02/26] reset: Add Allwinner RESET driver

[Jagan Teki]

Add common reset driver for all Allwinner SoC's.

Since CLK and RESET share common DT compatible, it is CLK driver
job is to bind the reset driver. So add CLK bind call on respective
SoC driver by passing ccu map descriptor so-that reset deassert,
deassert operations held based on ccu reset table defined from
CLK driver.

Select DM_RESET via CLK_SUNXI, this make hidden section of RESET
since CLK and RESET share common DT compatible and code.

Signed-off-by: Jagan Teki 
Acked-by: Maxime Ripard 
---
Changes for v5.1:
- s/CCU_CLK_F_INIT_DONE/CCU_CLK_F_IS_VALID
- Add CCU_RST_F_IS_VALID flag
- Use ccu_flags instead of ccu_clk_flags since reset flags is included

 arch/arm/include/asm/arch-sunxi/ccu.h |  33 ++-
 drivers/clk/sunxi/Kconfig |   1 +
 drivers/clk/sunxi/clk_a64.c   |  20 +
 drivers/reset/Kconfig |   8 ++
 drivers/reset/Makefile|   1 +
 drivers/reset/reset-sunxi.c   | 125 ++
 6 files changed, 187 insertions(+), 1 deletion(-)
 create mode 100644 drivers/reset/reset-sunxi.c

diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h 
b/arch/arm/include/asm/arch-sunxi/ccu.h
index 24efe0ab0a..5dd97ab227 100644
--- a/arch/arm/include/asm/arch-sunxi/ccu.h
+++ b/arch/arm/include/asm/arch-sunxi/ccu.h
@@ -8,12 +8,14 @@
 #define _ASM_ARCH_CCU_H
 
 /**
- * enum ccu_flags - ccu clock flags
+ * enum ccu_flags - ccu clock/reset flags
  *
  * @CCU_CLK_F_IS_VALID:is given clock gate is valid?
+ * @CCU_RST_F_IS_VALID:is given reset control is valid?
  */
 enum ccu_flags {
CCU_CLK_F_IS_VALID  = BIT(0),
+   CCU_RST_F_IS_VALID  = BIT(1),
 };
 
 /**
@@ -34,13 +36,33 @@ struct ccu_clk_gate {
.flags = CCU_CLK_F_IS_VALID,\
 }
 
+/**
+ * struct ccu_reset - ccu reset
+ * @off:   reset offset
+ * @bit:   reset bit
+ * @flags: ccu reset control flags
+ */
+struct ccu_reset {
+   u16 off;
+   u32 bit;
+   enum ccu_flags flags;
+};
+
+#define RESET(_off, _bit) {\
+   .off = _off,\
+   .bit = _bit,\
+   .flags = CCU_RST_F_IS_VALID,\
+}
+
 /**
  * struct ccu_desc - clock control unit descriptor
  *
  * @gates: clock gates
+ * @resets:reset unit
  */
 struct ccu_desc {
const struct ccu_clk_gate *gates;
+   const struct ccu_reset *resets;
 };
 
 /**
@@ -62,4 +84,13 @@ int sunxi_clk_probe(struct udevice *dev);
 
 extern struct clk_ops sunxi_clk_ops;
 
+/**
+ * sunxi_reset_bind() - reset binding
+ *
+ * @dev:   reset device
+ * @count: reset count
+ * @return 0 success, or error value
+ */
+int sunxi_reset_bind(struct udevice *dev, ulong count);
+
 #endif /* _ASM_ARCH_CCU_H */
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf5ecb3801..041d711e58 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -1,6 +1,7 @@
 config CLK_SUNXI
bool "Clock support for Allwinner SoCs"
depends on CLK && ARCH_SUNXI
+   select DM_RESET
default y
help
  This enables support for common clock driver API on Allwinner
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index 803a2f711d..28bda1f497 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static const struct ccu_clk_gate a64_gates[] = {
[CLK_BUS_OTG]   = GATE(0x060, BIT(23)),
@@ -26,10 +27,28 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
 };
 
+static const struct ccu_reset a64_resets[] = {
+   [RST_USB_PHY0]  = RESET(0x0cc, BIT(0)),
+   [RST_USB_PHY1]  = RESET(0x0cc, BIT(1)),
+   [RST_USB_HSIC]  = RESET(0x0cc, BIT(2)),
+
+   [RST_BUS_OTG]   = RESET(0x2c0, BIT(23)),
+   [RST_BUS_EHCI0] = RESET(0x2c0, BIT(24)),
+   [RST_BUS_EHCI1] = RESET(0x2c0, BIT(25)),
+   [RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
+   [RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
+};
+
 static const struct ccu_desc a64_ccu_desc = {
.gates = a64_gates,
+   .resets = a64_resets,
 };
 
+static int a64_clk_bind(struct udevice *dev)
+{
+   return sunxi_reset_bind(dev, 50);
+}
+
 static const struct udevice_id a64_ccu_ids[] = {
{ .compatible = "allwinner,sun50i-a64-ccu",
  .data = (ulong)_ccu_desc },
@@ -43,4 +62,5 @@ U_BOOT_DRIVER(clk_sun50i_a64) = {
.priv_auto_alloc_size   = sizeof(struct ccu_priv),
.ops= _clk_ops,
.probe  = sunxi_clk_probe,
+   .bind   = a64_clk_bind,
 };
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9c5208b7da..b6b40b6ce9 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -106,4 +106,12 @@ config RESET_SOCFPGA
help

Re: [U-Boot] dm: pinctrl: Prevent (re-)configuring pins when already done before relocation

[Alex Kiernan]

On Thu, Dec 27, 2018 at 3:49 PM Tom Rini  wrote:
>
> On Tue, Dec 18, 2018 at 12:30:50PM +0100, Lukasz Majewski wrote:
>
> > This commit prevents from re-configuring pins if those were configured
> > before relocation.
> >
> > Some pins - like UART or DDR must be setup before relocation
> > (as they have 'u-boot,dm-pre-reloc' property set in DTS). Without this
> > change, those pins are re-configured after relocation (pre_reloc_only = 0,
> > so we do not "continue").
> > Such behavior may be a problem for DDR PAD configuration, as they might
> > be already leveled/tuned with original setup).
> >
> > Signed-off-by: Lukasz Majewski 
>
> Applied to u-boot/master, thanks!
>

I've bisected out to this commit and it's slightly broken things for
me on an AM3352. It all works fine so long as I boot MLO from MMC (so
the MMC is probed, pinctrl setup), but if I boot from UART then I get
to full U-Boot, MMC hasn't been probed and the pinmuxing isn't set up
for the MMC.

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

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Laszlo Ersek]

On 01/08/19 16:12, Gao, Liming wrote:

> Last, EFI_HII_KEYBOARD_PACKAGE_HDR structure definition doesn't follow UEFI 
> spec. I remember we ever meet with the compiler issue for below style. GCC49 
> may complaint it. I need to double confirm. 
> typedef struct {
>   EFI_HII_PACKAGE_HEADER  Header;
>   UINT16  LayoutCount;
>   EFI_HII_KEYBOARD_LAYOUT Layout[];
> } EFI_HII_KEYBOARD_PACKAGE_HDR;

This is called "flexible array member", and it was introduced in ISO
C99. It is not part of the earlier C standards, and I quite expect
several of the toolchains currently supported by edk2 to reject it.


Code written against earlier releases of the ISO C standard than C99
would use a construct colloquially called the "struct hack", such as

  typedef struct {
EFI_HII_PACKAGE_HEADER  Header;
UINT16  LayoutCount;
EFI_HII_KEYBOARD_LAYOUT Layout[1];
  } EFI_HII_KEYBOARD_PACKAGE_HDR;

indexing "Layout" with a subscript >= 1. Needless to say, that was
always undefined behavior :) C99 introduced the flexible array member
precisely for covering the "struct hack" use case with a well-defined
construct.

There is no portable, pre-C99 way to actually spell out the Layout field
in the structure definition, with the intended use case. The most
portable approach I can think of would be:

- explain the trailing (nameless) array in a comment,
- instruct programmers to write manual pointer-to-unsigned-char arithmetic,
- once the necessary element is located, copy it into an object actually
declared with the element type, and access it there.

In edk2 we sometimes do steps #1 and #2, which is OK. But, even in those
cases, we almost never do step #3 (because it's both cumbersome and
wastes cycles) -- instead, we favor type-punning.

Whenever I see that, I tell myself, "we disable the effective type rules
with '-fno-strict-aliasing', so this should be fine, in practice. I hope
anyway." :)

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

[U-Boot] [PATCH v4 1/1] efi_loader: refactor switch to non-secure mode

[Heinrich Schuchardt]

Refactor the switch from supervisor to hypervisor to a new function called
at the beginning of do_bootefi().

Signed-off-by: Heinrich Schuchardt 
---
v4
Correct comments.
Use tab in Makefile.
v3
Move weak function to common/bootm.c.
Rename functions.
Add more comments.
Avoid static variable for jump buffer.
v2
Use weak function with implementation in arch directories
---
 arch/arm/cpu/armv7/Makefile  |  1 +
 arch/arm/cpu/armv7/exception_level.c | 56 ++
 arch/arm/cpu/armv8/Makefile  |  1 +
 arch/arm/cpu/armv8/exception_level.c | 55 +
 cmd/bootefi.c| 72 ++--
 common/bootm.c   | 10 
 include/bootm.h  |  5 ++
 7 files changed, 132 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/exception_level.c
 create mode 100644 arch/arm/cpu/armv8/exception_level.c

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 4f4647c90ac..8c955d0d528 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SYS_ARM_MPU) += mpu_v7r.o
 
 ifneq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_EFI_LOADER) += sctlr.o
+obj-$(CONFIG_ARMV7_NONSEC) += exception_level.o
 endif
 
 ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
diff --git a/arch/arm/cpu/armv7/exception_level.c 
b/arch/arm/cpu/armv7/exception_level.c
new file mode 100644
index 000..e116435623f
--- /dev/null
+++ b/arch/arm/cpu/armv7/exception_level.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Switch to non-secure mode
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ *
+ * This module contains the ARMv7 specific code required for leaving the
+ * secure mode before booting an operating system.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * entry_non_secure() - entry point when switching to non-secure mode
+ *
+ * When switching to non-secure mode switch_to_non_secure_mode() calls this
+ * function passing a jump buffer. We use this jump buffer to restore the
+ * original stack and register state.
+ *
+ * @non_secure_jmp:jump buffer for restoring stack and registers
+ */
+static void entry_non_secure(struct jmp_buf_data *non_secure_jmp)
+{
+   dcache_enable();
+   debug("Reached non-secure mode\n");
+
+   /* Restore stack and registers saved in switch_to_non_secure_mode() */
+   longjmp(non_secure_jmp, 1);
+}
+
+/**
+ * switch_to_non_secure_mode() - switch to non-secure mode
+ *
+ * Operating systems may expect to run in non-secure mode. Here we check if
+ * we are running in secure mode and switch to non-secure mode if necessary.
+ */
+void switch_to_non_secure_mode(void)
+{
+   static bool is_nonsec;
+   struct jmp_buf_data non_secure_jmp;
+
+   if (armv7_boot_nonsec() && !is_nonsec) {
+   if (setjmp(_secure_jmp))
+   return;
+   dcache_disable();   /* flush cache before switch to HYP */
+   armv7_init_nonsec();
+   is_nonsec = true;
+   secure_ram_addr(_do_nonsec_entry)(entry_non_secure,
+ (uintptr_t)_secure_jmp,
+ 0, 0);
+   }
+}
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 52c8daa0496..8b0b887a696 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -14,6 +14,7 @@ ifdef CONFIG_SPL_BUILD
 obj-$(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) += exceptions.o
 else
 obj-y  += exceptions.o
+obj-y  += exception_level.o
 endif
 obj-y  += cache.o
 obj-y  += tlb.o
diff --git a/arch/arm/cpu/armv8/exception_level.c 
b/arch/arm/cpu/armv8/exception_level.c
new file mode 100644
index 000..245af3f1d4e
--- /dev/null
+++ b/arch/arm/cpu/armv8/exception_level.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Switch to non-secure mode
+ *
+ * Copyright (c) 2018 Heinrich Schuchardt
+ *
+ * This module contains the ARMv8 specific code required to adjust the 
exception
+ * level before booting an operating system.
+ */
+
+#include 
+#include 
+#include 
+
+/**
+ * entry_non_secure() - entry point when switching to non-secure mode
+ *
+ * When switching to non-secure mode switch_to_non_secure_mode() calls this
+ * function passing a jump buffer. We use this jump buffer to restore the
+ * original stack and register state.
+ *
+ * @non_secure_jmp:jump buffer for restoring stack and registers
+ */
+static void entry_non_secure(struct jmp_buf_data *non_secure_jmp)
+{
+   dcache_enable();
+   debug("Reached non-secure mode\n");
+
+   /* Restore stack and registers saved in switch_to_non_secure_mode() */
+   longjmp(non_secure_jmp, 1);
+}
+
+/**
+ * switch_to_non_secure_mode() - switch to non-secure mode
+ *
+ * Exception level EL3 is meant to be used by the secure monitor only 

Re: [U-Boot] [PATCH 2/2] mmc: jz_mmc: Compile-out write support if disabled

[Daniel Schwierzeck]

Am 07.01.19 um 22:13 schrieb Ezequiel Garcia:
> Do not build write support, unless it's enabled.
> 
> In the SPL case, this change will typically remove
> precious bytes (as write support is most often
> not needed in SPL).
> 
> This is important on this platform, where the maximum
> SPL size is 14 KiB.
> 
> With gcc v7.3, this change saves 144 bytes producing:
> 
> size spl/u-boot-spl
>text  data bss dec hex filename
>9240   752 712   1070429d0 spl/u-boot-spl
> 
> To make the code easier to compile-out and more
> readable, a pair of read_data/write_data helpers are created.
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/mmc/jz_mmc.c | 105 +--
>  1 file changed, 61 insertions(+), 44 deletions(-)
> 

Reviewed-by: Daniel Schwierzeck 

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

Re: [U-Boot] [PATCH 1/2] mmc: Use proper IS_ENABLED macro to check block support

[Daniel Schwierzeck]

Am 07.01.19 um 22:13 schrieb Ezequiel Garcia:
> Use CONFIG_IS_ENABLED(BLK) instead of CONFIG_BLK,
> in order to fix the following build issues when
> CONFIG_SPL_MMC_WRITE is selected:
> 
> drivers/mmc/mmc_write.c:69:7: error: conflicting types for 'mmc_berase'
>  ulong mmc_berase(struct udevice *dev, lbaint_t start, lbaint_t blkcnt)
>^~
> In file included from drivers/mmc/mmc_write.c:15:0:
> drivers/mmc/mmc_private.h:39:7: note: previous declaration of 'mmc_berase' 
> was here
>  ulong mmc_berase(struct blk_desc *block_dev, lbaint_t start, lbaint_t 
> blkcnt);
>^~
> drivers/mmc/mmc_write.c:187:7: error: conflicting types for 'mmc_bwrite'
>  ulong mmc_bwrite(struct udevice *dev, lbaint_t start, lbaint_t blkcnt,
>^~
> In file included from drivers/mmc/mmc_write.c:15:0:
> drivers/mmc/mmc_private.h:37:7: note: previous declaration of 'mmc_bwrite' 
> was here
>  ulong mmc_bwrite(struct blk_desc *block_dev, lbaint_t start, lbaint_t blkcnt,
>^~
> 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/mmc/mmc_write.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

Reviewed-by: Daniel Schwierzeck 

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

Re: [U-Boot] [PATCH v2 1/7] pinctrl: mscc: Add gpio and pinctrl for Jaguar2 SOC family

[Daniel Schwierzeck]

Am 08.01.19 um 09:00 schrieb Horatiu Vultur:
> Hi Daniel,
> 
> The 01/07/2019 20:38, Daniel Schwierzeck wrote:
>>
>>
>> Am 07.01.19 um 14:02 schrieb Horatiu Vultur:
>>> The Jaguar2 SOC family has 63 gpio pins therefore I extended mscc-common
>>> to support new numbe of pins.
>>>
>>> Signed-off-by: Horatiu Vultur 
>>> ---
>>>  MAINTAINERS|   1 +
>>>  drivers/pinctrl/mscc/Kconfig   |   9 +
>>>  drivers/pinctrl/mscc/Makefile  |   1 +
>>>  drivers/pinctrl/mscc/mscc-common.c |  97 ---
>>>  drivers/pinctrl/mscc/mscc-common.h |   5 +
>>>  drivers/pinctrl/mscc/pinctrl-jr2.c | 342 
>>> +
>>>  6 files changed, 433 insertions(+), 22 deletions(-)
>>>  create mode 100644 drivers/pinctrl/mscc/pinctrl-jr2.c
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 494962e..495d3e5 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -525,6 +525,7 @@ F:  board/mscc/
>>>  F: configs/mscc*
>>>  F: drivers/gpio/mscc_sgpio.c
>>>  F: include/configs/vcoreiii.h
>>> +F: drivers/pinctrl/mscc/
>>>  
>>>  MIPS JZ4780
>>>  M: Ezequiel Garcia 
>>> diff --git a/drivers/pinctrl/mscc/Kconfig b/drivers/pinctrl/mscc/Kconfig
>>> index cfc6c06..d07ea1b 100644
>>> --- a/drivers/pinctrl/mscc/Kconfig
>>> +++ b/drivers/pinctrl/mscc/Kconfig
>>> @@ -20,3 +20,12 @@ config PINCTRL_MSCC_LUTON
>>> help
>>>Support pin multiplexing and pin configuration control on
>>>Microsemi luton SoCs.
>>> +
>>> +config PINCTRL_MSCC_JR2
>>> +   depends on SOC_JR2 && PINCTRL_FULL && OF_CONTROL
>>> +   select PINCTRL_MSCC
>>> +   default y
>>> +   bool "Microsemi jr2 family pin control driver"
>>> +   help
>>> +   Support pin multiplexing and pin configuration control on
>>> +   Microsemi jr2 SoCs.
>>> diff --git a/drivers/pinctrl/mscc/Makefile b/drivers/pinctrl/mscc/Makefile
>>> index 6910671..8038d54 100644
>>> --- a/drivers/pinctrl/mscc/Makefile
>>> +++ b/drivers/pinctrl/mscc/Makefile
>>> @@ -3,3 +3,4 @@
>>>  obj-y += mscc-common.o
>>>  obj-$(CONFIG_PINCTRL_MSCC_OCELOT) += pinctrl-ocelot.o
>>>  obj-$(CONFIG_PINCTRL_MSCC_LUTON) += pinctrl-luton.o
>>> +obj-$(CONFIG_PINCTRL_MSCC_JR2) += pinctrl-jr2.o
>>> diff --git a/drivers/pinctrl/mscc/mscc-common.c 
>>> b/drivers/pinctrl/mscc/mscc-common.c
>>> index d74b8a6..7743565 100644
>>> --- a/drivers/pinctrl/mscc/mscc-common.c
>>> +++ b/drivers/pinctrl/mscc/mscc-common.c
>>> @@ -22,6 +22,18 @@
>>>  #include 
>>>  #include "mscc-common.h"
>>>  
>>> +#if defined(CONFIG_SOC_JR2)
>>> +#define MSCC_GPIO_OUT_SET  0x00
>>> +#define MSCC_GPIO_OUT_CLR  0x08
>>> +#define MSCC_GPIO_OUT  0x10
>>> +#define MSCC_GPIO_IN   0x18
>>> +#define MSCC_GPIO_OE   0x20
>>> +#define MSCC_GPIO_INTR 0x28
>>> +#define MSCC_GPIO_INTR_ENA 0x30
>>> +#define MSCC_GPIO_INTR_IDENT   0x38
>>> +#define MSCC_GPIO_ALT0 0x40
>>> +#define MSCC_GPIO_ALT1 0x48
>>> +#else
>>
>> you should also move this to pinctrl-jr2.c
> 
> If I will move also this in pinctrl-jr2 then I will need to mark many
> functions as weak and implement them in pinctrl-jr2. And thier
> implementation will be the same. Another reason why not to move them in
> pinctr-jr2 is that soon we want to add support for another target which
> has same features as JR2.
> 
> Maybe another solution is to extend the function mscc_pinctrl_probe to
> receive also an array with the offset of MSCC_GPIO_*. And then each
> specific pinctrl will need to pass this array, similar with mscc_pins.
> In this way the mscc-common will not contain any specific code to any of
> the targets.

yes, that's even better than __weak. This technique is also used in
other drivers where register offset mappings are selected via DT
compatible string. One example I know of is drivers/spi/bcm63xx_spi.c.

> 
>>
>>>  #define MSCC_GPIO_OUT_SET  0x0
>>>  #define MSCC_GPIO_OUT_CLR  0x4
>>>  #define MSCC_GPIO_OUT  0x8
>>> @@ -32,6 +44,39 @@
>>>  #define MSCC_GPIO_INTR_IDENT   0x1c
>>>  #define MSCC_GPIO_ALT0 0x20
>>>  #define MSCC_GPIO_ALT1 0x24
>>> +#endif
>>> +
>>> +static void mscc_writel(unsigned int offset, void *addr)
>>> +{
>>> +   if (offset < 32)
>>> +   writel(BIT(offset), addr);
>>> +   else
>>> +   writel(BIT(offset % 32), addr + 4);
>>> +}
>>> +
>>> +static unsigned int mscc_readl(unsigned int offset, void *addr)
>>> +{
>>> +   if (offset < 32)
>>> +   return readl(addr);
>>> +   else
>>> +   return readl(addr + 4);
>>> +}
>>> +
>>> +void mscc_setbits(unsigned int offset, void *addr)
>>> +{
>>> +   if (offset < 32)
>>> +   writel(readl(addr) | BIT(offset), addr);
>>> +   else
>>> +   writel(readl(addr + 4) | BIT(offset % 32), addr + 4);
>>> +}
>>> +
>>> +void mscc_clrbits(unsigned int offset, void *addr)
>>> +{
>>> +   if (offset < 32)
>>> +   writel(readl(addr) & ~BIT(offset), addr);
>>> +   else
>>> +   writel(readl(addr + 4) & 

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Leif Lindholm]

Thanks Liming, this exactly the reply I was hoping for.

On Tue, Jan 08, 2019 at 03:12:11PM +, Gao, Liming wrote:
> EFI_GUID structure definition follows RFC UUID
> https://www.ietf.org/rfc/rfc4122.txt. This RFC has no 64 bit
> boundary requirement. I don't know the background why UEFI spec
> requires to align on 64-bit boundary. This may be true for early IPF
> arch. UEFI forum can clarify its purpose. If no specific reason, I
> suggest to follow the industry standard GUID format, and update UEFI
> spec.

Since there would be no 64-bit alignment requirements for IPF either
for correctness reasons, I expect it was added for performance reasons.

> On pack in structure EFI_HII_KEYBOARD_LAYOUT, UEFI2.7 32.3 Code
> Definitions has one sentence that this chapter describes the binary
> encoding of the different package types. 32.3.3 Font Package has the
> additional statement that structures described here are byte
> packed. Base on those description, we can infer HII package data is
> the byte packed. I agree to obviously specify that structures
> described here are byte packed in 32.3 section.

That sounds good to me.

> Last, EFI_HII_KEYBOARD_PACKAGE_HDR structure definition doesn't
> follow UEFI spec. I remember we ever meet with the compiler issue
> for below style. GCC49 may complaint it. I need to double confirm.
> typedef struct {
>   EFI_HII_PACKAGE_HEADER  Header;
>   UINT16  LayoutCount;
>   EFI_HII_KEYBOARD_LAYOUT Layout[];
> } EFI_HII_KEYBOARD_PACKAGE_HDR;

I did remark on this to Ard, and he pointed out the old compiler
issue. If I delete those comment markers, I cannot reproduce a problem
with either GCC48 or GCC49 (on those actual compiler versions) on ARM.

Right, I will put together an email to USWG with you on cc.

Regards,

Leif

> 
> Thanks
> Liming
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com]
> > Sent: Tuesday, January 8, 2019 7:56 PM
> > To: Leif Lindholm 
> > Cc: AKASHI Takahiro ; Alexander Graf 
> > ; Heinrich Schuchardt ;
> > tr...@konsulko.com; robdcl...@gmail.com; u-boot@lists.denx.de; 
> > edk2-de...@lists.01.org; Wang, Jian J ; Wu,
> > Hao A ; Ni, Ray ; Zeng, Star 
> > ; Andrew Fish ; Kinney,
> > Michael D ; Ard Biesheuvel 
> > ; Gao, Liming 
> > Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database 
> > protocols
> > 
> > On 01/08/19 10:51, Leif Lindholm wrote:
> > > MdePkg/MdeModulePkg maintainers - any comments?
> > >
> > > On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote:
> > >> On 01/07/19 20:22, Leif Lindholm wrote:
> > >>> On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
> > >>
> >  The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
> >  unless specified otherwise. See in "Table 5. Common UEFI Data Types":
> > 
> >    EFI_GUID -- 128-bit buffer containing a unique identifier value.
> >    Unless otherwise specified, aligned on a 64-bit
> >    boundary.
> > >>>
> > >>> Indeed.
> > >>>
> >  Whether edk2 satisfies that, and if so, how (by chance / by general
> >  build flags), I don't know. The code says,
> > 
> >  ///
> >  /// 128 bit buffer containing a unique identifier value.
> >  /// Unless otherwise specified, aligned on a 64 bit boundary.
> >  ///
> >  typedef struct {
> >    UINT32  Data1;
> >    UINT16  Data2;
> >    UINT16  Data3;
> >    UINT8   Data4[8];
> >  } GUID;
> > 
> >  I think there may have been an expectation in "MdePkg/Include/Base.h"
> >  that the supported compilers would automatically ensure the specified
> >  alignment, given the structure definition.
> > >>>
> > >>> But that would be expecting things not only not guaranteed by C, but
> > >>> something there is no semantic information suggesting would be useful
> > >>> for the compiler to do above. [...]
> > >>
> > >> Agreed. I'm not saying the edk2 code is right, just guessing why the
> > >> code might look like it does. This would not be the first silent
> > >> assumption, I think.
> > >>
> > >> Anyhow, I think it would be better to change the code than the spec.
> > >
> > > Of course it would be better to change the code than the spec.
> > >
> > > But as Ard points out off-thread, doing (as a hack, with gcc)
> > >
> > > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> > > b/MdePkg/Include/Uefi/UefiBaseType.h
> > > index 8c9d571eb1..75409f3460 100644
> > > --- a/MdePkg/Include/Uefi/UefiBaseType.h
> > > +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> > > @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> > > EITHER EXPRESS OR IMPLIED.
> > >  ///
> > >  /// 128-bit buffer containing a unique identifier value.
> > >  ///
> > > -typedef GUID  EFI_GUID;
> > > +typedef GUID  EFI_GUID __attribute__((aligned (8)));
> > >  ///
> > >  /// Function return status for EFI API.
> > >  ///
> > >
> > > breaks Linux boot on ARM 

Re: [U-Boot] [U-Boot, v2, 1/2] cmd: bmp: Make integer-to-pointer cast platform, independent

[Alexander Graf]

> This patch fixes the int-to-pointer-cast warning on aarch64.
> 
> Signed-off-by: Adam Heinrich 

Thanks, applied to rpi-next

Alex

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

Re: [U-Boot] [PATCH v2 2/2] rpi: Enable command bmp

[Alexander Graf]

On 31.12.18 12:11, Adam Heinrich wrote:
> This patch enables the bmp command (with gzip support enabled) on all
> Raspberry Pi boards.
> 
> The value of CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (required by
> CONFIG_VIDEO_BMP_GZIP) is set to match resolution of the "official"
> 7 inch LCD.
> 
> Signed-off-by: Adam Heinrich 
> Cc: Alexander Graf 
> ---
>  configs/rpi_0_w_defconfig   | 1 +
>  configs/rpi_2_defconfig | 1 +
>  configs/rpi_3_32b_defconfig | 1 +
>  configs/rpi_3_defconfig | 1 +
>  configs/rpi_defconfig   | 1 +
>  include/configs/rpi.h   | 7 +++
>  6 files changed, 12 insertions(+)
> 
> diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
> index 66b0de31b6..18b7cfef76 100644
> --- a/configs/rpi_0_w_defconfig
> +++ b/configs/rpi_0_w_defconfig
> @@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_CMD_BMP=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
> index ba75e52dda..6c04a622ff 100644
> --- a/configs/rpi_2_defconfig
> +++ b/configs/rpi_2_defconfig
> @@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_CMD_BMP=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
> index bbcdd91e90..c856621a03 100644
> --- a/configs/rpi_3_32b_defconfig
> +++ b/configs/rpi_3_32b_defconfig
> @@ -10,6 +10,7 @@ CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_CMD_BMP=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
> index 54b6303c2d..7d2eff0517 100644
> --- a/configs/rpi_3_defconfig
> +++ b/configs/rpi_3_defconfig
> @@ -10,6 +10,7 @@ CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_CMD_BMP=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
> index e7820cb147..7b3f82c0d3 100644
> --- a/configs/rpi_defconfig
> +++ b/configs/rpi_defconfig
> @@ -9,6 +9,7 @@ CONFIG_MISC_INIT_R=y
>  # CONFIG_DISPLAY_CPUINFO is not set
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_CMD_BMP=y
>  # CONFIG_CMD_FLASH is not set
>  CONFIG_CMD_GPIO=y
>  CONFIG_CMD_MMC=y
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index 9ce41767a9..284e3a98de 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -63,6 +63,13 @@
>  #define CONFIG_LCD_DT_SIMPLEFB
>  #define CONFIG_VIDEO_BCM2835
> 
> +#ifdef CONFIG_DM_VIDEO
> +#define CONFIG_BMP_24BPP
> +#define CONFIG_BMP_32BPP
> +#define CONFIG_VIDEO_BMP_GZIP
> +#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE  ((800 * 480 * 4) + 54)

This doesn't seem correct: IIUC the RPi can display up to Full HD, no?

Also, doesn't gzip contain a header that actually tells us the target
size? Why do we have to unconditionally allocate
CONFIG_SYS_VIDEO_LOGO_MAX_SIZE in the first place?

Furthermore I'm missing the rationale here: Why do you need the bmp
command? What exactly are you trying to do? Is there maybe a better
(more platform agnostic) solution for that? The bmp command seems to be
quite unmaintained.


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

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Gao, Liming]

EFI_GUID structure definition follows RFC UUID 
https://www.ietf.org/rfc/rfc4122.txt. This RFC has no 64 bit boundary 
requirement. I don't know the background why UEFI spec requires to align on 
64-bit boundary. This may be true for early IPF arch. UEFI forum can clarify 
its purpose. If no specific reason, I suggest to follow the industry standard 
GUID format, and update UEFI spec. 

On pack in structure EFI_HII_KEYBOARD_LAYOUT, UEFI2.7 32.3 Code Definitions has 
one sentence that this chapter describes the binary encoding of the different 
package types. 32.3.3 Font Package has the additional statement that structures 
described here are byte packed. Base on those description, we can infer HII 
package data is the byte packed. I agree to obviously specify that structures 
described here are byte packed in 32.3 section.

Last, EFI_HII_KEYBOARD_PACKAGE_HDR structure definition doesn't follow UEFI 
spec. I remember we ever meet with the compiler issue for below style. GCC49 
may complaint it. I need to double confirm. 
typedef struct {
  EFI_HII_PACKAGE_HEADER  Header;
  UINT16  LayoutCount;
  EFI_HII_KEYBOARD_LAYOUT Layout[];
} EFI_HII_KEYBOARD_PACKAGE_HDR;

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, January 8, 2019 7:56 PM
> To: Leif Lindholm 
> Cc: AKASHI Takahiro ; Alexander Graf 
> ; Heinrich Schuchardt ;
> tr...@konsulko.com; robdcl...@gmail.com; u-boot@lists.denx.de; 
> edk2-de...@lists.01.org; Wang, Jian J ; Wu,
> Hao A ; Ni, Ray ; Zeng, Star 
> ; Andrew Fish ; Kinney,
> Michael D ; Ard Biesheuvel 
> ; Gao, Liming 
> Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols
> 
> On 01/08/19 10:51, Leif Lindholm wrote:
> > MdePkg/MdeModulePkg maintainers - any comments?
> >
> > On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote:
> >> On 01/07/19 20:22, Leif Lindholm wrote:
> >>> On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
> >>
>  The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
>  unless specified otherwise. See in "Table 5. Common UEFI Data Types":
> 
>    EFI_GUID -- 128-bit buffer containing a unique identifier value.
>    Unless otherwise specified, aligned on a 64-bit
>    boundary.
> >>>
> >>> Indeed.
> >>>
>  Whether edk2 satisfies that, and if so, how (by chance / by general
>  build flags), I don't know. The code says,
> 
>  ///
>  /// 128 bit buffer containing a unique identifier value.
>  /// Unless otherwise specified, aligned on a 64 bit boundary.
>  ///
>  typedef struct {
>    UINT32  Data1;
>    UINT16  Data2;
>    UINT16  Data3;
>    UINT8   Data4[8];
>  } GUID;
> 
>  I think there may have been an expectation in "MdePkg/Include/Base.h"
>  that the supported compilers would automatically ensure the specified
>  alignment, given the structure definition.
> >>>
> >>> But that would be expecting things not only not guaranteed by C, but
> >>> something there is no semantic information suggesting would be useful
> >>> for the compiler to do above. [...]
> >>
> >> Agreed. I'm not saying the edk2 code is right, just guessing why the
> >> code might look like it does. This would not be the first silent
> >> assumption, I think.
> >>
> >> Anyhow, I think it would be better to change the code than the spec.
> >
> > Of course it would be better to change the code than the spec.
> >
> > But as Ard points out off-thread, doing (as a hack, with gcc)
> >
> > diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> > b/MdePkg/Include/Uefi/UefiBaseType.h
> > index 8c9d571eb1..75409f3460 100644
> > --- a/MdePkg/Include/Uefi/UefiBaseType.h
> > +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> > @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> > EITHER EXPRESS OR IMPLIED.
> >  ///
> >  /// 128-bit buffer containing a unique identifier value.
> >  ///
> > -typedef GUID  EFI_GUID;
> > +typedef GUID  EFI_GUID __attribute__((aligned (8)));
> >  ///
> >  /// Function return status for EFI API.
> >  ///
> >
> > breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding
> > between ConfigurationTable entries in the system table.
> 
> (
> 
> More precisely, it adds padding to EFI_CONFIGURATION_TABLE after
> "VendorGuid" or after "VendorTable". Padding may not be added at the
> beginning of structures, and may not be added anywhere to arrays.
> 
> The practical effect is the same, so this is just a side comment about C.
> 
> )
> 
> Thanks
> Laszlo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [edk2] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Bi, Dandan]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Leif Lindholm
> Sent: Tuesday, January 08, 2019 5:51 PM
> To: Laszlo Ersek 
> Cc: Ni, Ray ; tr...@konsulko.com; AKASHI Takahiro
> ; Wu, Hao A ; Heinrich
> Schuchardt ; edk2-de...@lists.01.org; Alexander
> Graf ; Gao, Liming ; u-
> b...@lists.denx.de; robdcl...@gmail.com; Kinney, Michael D
> ; Zeng, Star 
> Subject: Re: [edk2] [RESEND PATCH v2 2/6] efi_loader: Initial HII database
> protocols
> 
> MdePkg/MdeModulePkg maintainers - any comments?
> 
> On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote:
> > On 01/07/19 20:22, Leif Lindholm wrote:
> > > On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
> >
> > >> The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit
> > >> aligned, unless specified otherwise. See in "Table 5. Common UEFI Data
> Types":
> > >>
> > >>   EFI_GUID -- 128-bit buffer containing a unique identifier value.
> > >>   Unless otherwise specified, aligned on a 64-bit
> > >>   boundary.
> > >
> > > Indeed.
> > >
> > >> Whether edk2 satisfies that, and if so, how (by chance / by general
> > >> build flags), I don't know. The code says,
> > >>
> > >> ///
> > >> /// 128 bit buffer containing a unique identifier value.
> > >> /// Unless otherwise specified, aligned on a 64 bit boundary.
> > >> ///
> > >> typedef struct {
> > >>   UINT32  Data1;
> > >>   UINT16  Data2;
> > >>   UINT16  Data3;
> > >>   UINT8   Data4[8];
> > >> } GUID;
> > >>
> > >> I think there may have been an expectation in
> "MdePkg/Include/Base.h"
> > >> that the supported compilers would automatically ensure the
> > >> specified alignment, given the structure definition.
> > >
> > > But that would be expecting things not only not guaranteed by C, but
> > > something there is no semantic information suggesting would be
> > > useful for the compiler to do above. [...]
> >
> > Agreed. I'm not saying the edk2 code is right, just guessing why the
> > code might look like it does. This would not be the first silent
> > assumption, I think.
> >
> > Anyhow, I think it would be better to change the code than the spec.
> 
> Of course it would be better to change the code than the spec.
> 
> But as Ard points out off-thread, doing (as a hack, with gcc)
> 
> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> b/MdePkg/Include/Uefi/UefiBaseType.h
> index 8c9d571eb1..75409f3460 100644
> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>  ///
>  /// 128-bit buffer containing a unique identifier value.
>  ///
> -typedef GUID  EFI_GUID;
> +typedef GUID  EFI_GUID __attribute__((aligned (8)));
>  ///
>  /// Function return status for EFI API.
>  ///
> 
> breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding
> between ConfigurationTable entries in the system table. So I don't see how
> that can realistically be fixed in the EDK2 codebase.
> 
> And with things like the EFI_HII_KEYBOARD_LAYOUT struct, if there has ever
> been compatibility between EDK2 and commercial BIOSes, then that struct
> has always been treated as packed (not just 32-bit aligned GUIDs), and the
> spec just needs to reflect reality. If there hasn't, then indeed the code
> change here would be trivial.

The structure definitions in Include/Uefi/UefiInternalFormRepresentation.h 
mainly describe the binary encoding of the different package types. And 
EFI_HII_KEYBOARD_LAYOUT struct is for the Keyboard Layout Package. 
Describing  the *binary encoding* of the different package type, so I think we 
should treat them as packed and it also should be the reason why they are 
packed now.  Maybe we can reflect this more clear in Spec.

> 
> (Adding Liming as well, since we're now discussing MdePkg also.)
> 
> Yes, this discussion belongs on USWG (UEFI specification working group
> mailing list), but I want to hear some comment from the package
> maintainers first.
> 
> Either way, I see a bunch of new SCT tests coming up.
> 
> /
> Leif
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Jean-Jacques Hiblot]

On 08/01/2019 15:11, Marek Vasut wrote:

On 1/8/19 2:57 PM, Lukasz Majewski wrote:

On Tue, 8 Jan 2019 14:37:49 +0100
Marek Vasut  wrote:


On 1/8/19 2:06 PM, Jean-Jacques Hiblot wrote:

On 08/01/2019 13:47, Marek Vasut wrote:

On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:

On 08/01/2019 12:18, Marek Vasut wrote:

On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:

This series applies on top of u-boot-dfu.

This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
CONFIG_SPL_USB_GADGET
for consistency.
It also uses CONFIG_USB_GADGET to compile-in the gadget code.
This make
sure that the code is not included if it is not needed. Some
defconfigs
had to be updated as they relied on the gadget code to be always
compiled.

TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900

Jean-Jacques Hiblot (2):
     Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
     usb: Make compiling gadget support optional

    Makefile | 4 ++--
    arch/arm/mach-imx/mx6/Kconfig    | 2 +-
    arch/arm/mach-imx/spl.c  | 2 +-
    common/spl/Kconfig   | 4 ++--
    configs/am335x_boneblack_vboot_defconfig | 2 +-
    configs/am335x_evm_usbspl_defconfig  | 2 +-
    configs/am43xx_evm_defconfig | 2 +-
    configs/am43xx_hs_evm_defconfig  | 2 +-
    configs/apalis_imx6_defconfig    | 2 +-
    configs/cm_t3517_defconfig   | 1 +
    configs/cm_t35_defconfig | 1 +
    configs/colibri_imx6_defconfig   | 2 +-
    configs/display5_factory_defconfig   | 2 +-
    configs/duovero_defconfig    | 1 +
    configs/igep0032_defconfig   | 1 +
    configs/igep00x0_defconfig   | 1 +
    configs/imx6q_logic_defconfig    | 2 +-
    configs/mx6memcal_defconfig  | 2 +-
    configs/mx6sabresd_defconfig | 2 +-
    configs/omap3_zoom1_defconfig    | 1 +
    configs/omap4_panda_defconfig    | 1 +
    configs/omap4_sdp4430_defconfig  | 1 +
    configs/pico-hobbit-imx6ul_defconfig | 2 +-
    configs/pico-hobbit-imx7d_defconfig  | 2 +-
    configs/pico-imx6ul_defconfig    | 2 +-
    configs/pico-imx7d_defconfig | 2 +-
    configs/pico-pi-imx6ul_defconfig | 2 +-
    configs/pico-pi-imx7d_defconfig  | 2 +-
    configs/spear300_usbtty_defconfig    | 2 ++
    configs/spear300_usbtty_nand_defconfig   | 2 ++
    configs/spear310_usbtty_defconfig    | 2 ++
    configs/spear310_usbtty_nand_defconfig   | 2 ++
    configs/spear310_usbtty_pnor_defconfig   | 2 ++
    configs/spear320_usbtty_defconfig    | 2 ++
    configs/spear320_usbtty_nand_defconfig   | 2 ++
    configs/spear320_usbtty_pnor_defconfig   | 2 ++
    configs/spear600_usbtty_defconfig    | 2 ++
    configs/spear600_usbtty_nand_defconfig   | 2 ++
    drivers/Makefile | 6 +++---
    drivers/usb/gadget/Makefile  | 2 +-
    scripts/Makefile.spl | 2 +-
    41 files changed, 55 insertions(+), 27 deletions(-)
  

I'll let Lukasz handle integrating this. Does it get rid of the
patch I complained about in the PR ? I hope so ..

I applies on top of u-boot-dfu and fixes the issue you complained
about.

It doesn't get rid of the patch per se but rather is a
complement.

Can they be squashed together somehow ?

IMO they make more sense as separate patches. but I see no problem
if Lukasz wants to squash them.

I'd prefer to replace the broken patch.



The patch to be replaced/amended is:
dm: usb: gadget: Fix boot breakage on sunxi platforms

I'm fine with adding those two patches on top of it.


Just changing the order should be enough to prevent any breakage.

1) Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET
2) usb: Make compiling gadget support optional
3) dm: usb: gadget: Fix boot breakage on sunxi platforms



Or do I miss something?

I don't want broken patches in the tree if it can be avoided, which in
this case is still possible.


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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Tom Rini]

On Tue, Jan 08, 2019 at 04:04:12PM +0100, Simon Goldschmidt wrote:
> Am 08.01.2019 um 15:58 schrieb Tom Rini:
> >On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote:
> >>On 1/8/19 3:48 PM, Tom Rini wrote:
> >>>On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> >On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
> >>
> >>On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> >>>On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
> 
> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> >On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> >>
> >>On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>>In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>>SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be 
> >>>disabled
> >>>via defconfig.
> >>>
> >>>This also seems to be required to use OF_PLATDATA, as the reset 
> >>>drivers
> >>>don't seem to work with it.
> >>
> >>How do you un-reset IP blocks if you disable the reset controller ?
> >
> >Here again, socfpga seems to be another bad example. Taking
> >peripherals out of reset
> >is cluttered throughout the mach-socfpga code at least in SPL. By now
> >I know socfpga is
> >lacking support for clock and reset management via devicetree. And
> >this is bad, I know,
> >but can we keep this a seperate issue from OF_PLATDATA?
> >
> >That being said, drivers/reset/reset-uclass.c fails to compile with
> >OF_PLATDATA, so I
> >guess this has not been used with OF_PLATDATA before. And given that 
> >I
> >don't seem
> >to need it for socfpga either, I don't think this would be the right
> >series to fix that.
> 
> Don't you need it to unreset at least the DWMMC or CQSPI ?
> >>>
> >>>Reading the code, it seems like that's taken care of through another 
> >>>hack in
> >>>spl_boot_device() ;-)
> >>
> >>Sigh.
> >>
> Anyway, I'd much prefer to start cleaning up the horrorshow that
> arch/arm/mach-socfpga is in terms of clock and reset, at least like 
> A10.
> Would that be possible ?
> >>>
> >>>I would be best, yes. I don't know when I will find the time to do 
> >>>that, though.
> >>>I don't know how much effort that would be, either. Is there maybe a 
> >>>patch
> >>>where A10 got converted from "as bad as gen5" to its current state? 
> >>>That
> >>>would help me to see if I can do it...
> >>
> >>A10 got switched to reset framework recently (in last 6 months or so),
> >>the reset driver is the same for Gen5 and A10 too, so it should be easy
> >>to recycle.
> >
> >Hmm, ok, let me check that... it would indeed be nice to port this to 
> >gen5.
> >
> >Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> >to continue on this? I mean, I thought I heard people here saying "use
> >OF_PLATDATA" if you're running out of space in SPL. After using it, I'm 
> >not too
> >keen on using it, either, but it does seem to give me some code space 
> >back...
> 
> OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
> This platform has a massive 60k of SRAM for SPL, so if we're running out
> of space, we're doing something wrong.
> >>>
> >>>It's not for "30k or below" but "needs more space to enable all desired
> >>>features inside of SPL".
> >>
> >>Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
> >>bloated that even platform with so much space has issues, how can we
> >>even cater for the rest of platforms with much more limited SPL ? And if
> >>that is the case, we have a much bigger problem ...
> >
> >It depends, greatly, on what features you want within a single binary.
> >I'm not saying SoCFPGA can't fit what it wants, including verified boot,
> >inside of 60k.  But what I am saying is we don't have a hard-and-fast
> >limit on when you must not use OF_PLATDATA since it's always been easy
> >to make SPL too big, once you start including all of the possible
> >kitchen sink options (lets do falcon mode, and boot count and usb gadget
> >and usb host and regular ethernet and mmc and nand and oh crap, where
> >did all of my space go?).
> 
> I'm not saying this was directed to me (I'm sure it wasn't). Just to clarify
> my point: I'm really just trying to get the most basic SPL to work that
> loads U-Boot as FIT from spi-flash and verifies it. It might well be that
> it's this verified FIT offset that could be reduced...

Oh no, I'm just listing the worst case of am335x, which is my fault, and
goes well over the generous 100k+ that we have available there.

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 3:58 PM, Tom Rini wrote:
> On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote:
>> On 1/8/19 3:48 PM, Tom Rini wrote:
>>> On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
 On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
>>
>> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:

 On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be 
>>> disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset 
>>> drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset controller ?
>
> Here again, socfpga seems to be another bad example. Taking
> peripherals out of reset
> is cluttered throughout the mach-socfpga code at least in SPL. By now
> I know socfpga is
> lacking support for clock and reset management via devicetree. And
> this is bad, I know,
> but can we keep this a seperate issue from OF_PLATDATA?
>
> That being said, drivers/reset/reset-uclass.c fails to compile with
> OF_PLATDATA, so I
> guess this has not been used with OF_PLATDATA before. And given that I
> don't seem
> to need it for socfpga either, I don't think this would be the right
> series to fix that.

 Don't you need it to unreset at least the DWMMC or CQSPI ?
>>>
>>> Reading the code, it seems like that's taken care of through another 
>>> hack in
>>> spl_boot_device() ;-)
>>
>> Sigh.
>>
 Anyway, I'd much prefer to start cleaning up the horrorshow that
 arch/arm/mach-socfpga is in terms of clock and reset, at least like 
 A10.
 Would that be possible ?
>>>
>>> I would be best, yes. I don't know when I will find the time to do 
>>> that, though.
>>> I don't know how much effort that would be, either. Is there maybe a 
>>> patch
>>> where A10 got converted from "as bad as gen5" to its current state? That
>>> would help me to see if I can do it...
>>
>> A10 got switched to reset framework recently (in last 6 months or so),
>> the reset driver is the same for Gen5 and A10 too, so it should be easy
>> to recycle.
>
> Hmm, ok, let me check that... it would indeed be nice to port this to 
> gen5.
>
> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> to continue on this? I mean, I thought I heard people here saying "use
> OF_PLATDATA" if you're running out of space in SPL. After using it, I'm 
> not too
> keen on using it, either, but it does seem to give me some code space 
> back...

 OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
 This platform has a massive 60k of SRAM for SPL, so if we're running out
 of space, we're doing something wrong.
>>>
>>> It's not for "30k or below" but "needs more space to enable all desired
>>> features inside of SPL".
>>
>> Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
>> bloated that even platform with so much space has issues, how can we
>> even cater for the rest of platforms with much more limited SPL ? And if
>> that is the case, we have a much bigger problem ...
> 
> It depends, greatly, on what features you want within a single binary.
> I'm not saying SoCFPGA can't fit what it wants, including verified boot,
> inside of 60k.  But what I am saying is we don't have a hard-and-fast
> limit on when you must not use OF_PLATDATA since it's always been easy
> to make SPL too big, once you start including all of the possible
> kitchen sink options (lets do falcon mode, and boot count and usb gadget
> and usb host and regular ethernet and mmc and nand and oh crap, where
> did all of my space go?).

Sure, but then maybe you do need to remove some of that stuff and
configure the SPL for that one single need you have.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

Am 08.01.2019 um 15:58 schrieb Tom Rini:

On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote:

On 1/8/19 3:48 PM, Tom Rini wrote:

On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:

On 1/8/19 1:46 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:


On 1/8/19 1:09 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:


On 1/8/19 7:24 AM, Simon Goldschmidt wrote:

On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:


On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


Here again, socfpga seems to be another bad example. Taking
peripherals out of reset
is cluttered throughout the mach-socfpga code at least in SPL. By now
I know socfpga is
lacking support for clock and reset management via devicetree. And
this is bad, I know,
but can we keep this a seperate issue from OF_PLATDATA?

That being said, drivers/reset/reset-uclass.c fails to compile with
OF_PLATDATA, so I
guess this has not been used with OF_PLATDATA before. And given that I
don't seem
to need it for socfpga either, I don't think this would be the right
series to fix that.


Don't you need it to unreset at least the DWMMC or CQSPI ?


Reading the code, it seems like that's taken care of through another hack in
spl_boot_device() ;-)


Sigh.


Anyway, I'd much prefer to start cleaning up the horrorshow that
arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
Would that be possible ?


I would be best, yes. I don't know when I will find the time to do that, though.
I don't know how much effort that would be, either. Is there maybe a patch
where A10 got converted from "as bad as gen5" to its current state? That
would help me to see if I can do it...


A10 got switched to reset framework recently (in last 6 months or so),
the reset driver is the same for Gen5 and A10 too, so it should be easy
to recycle.


Hmm, ok, let me check that... it would indeed be nice to port this to gen5.

Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
to continue on this? I mean, I thought I heard people here saying "use
OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
keen on using it, either, but it does seem to give me some code space back...


OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
This platform has a massive 60k of SRAM for SPL, so if we're running out
of space, we're doing something wrong.


It's not for "30k or below" but "needs more space to enable all desired
features inside of SPL".


Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
bloated that even platform with so much space has issues, how can we
even cater for the rest of platforms with much more limited SPL ? And if
that is the case, we have a much bigger problem ...


It depends, greatly, on what features you want within a single binary.
I'm not saying SoCFPGA can't fit what it wants, including verified boot,
inside of 60k.  But what I am saying is we don't have a hard-and-fast
limit on when you must not use OF_PLATDATA since it's always been easy
to make SPL too big, once you start including all of the possible
kitchen sink options (lets do falcon mode, and boot count and usb gadget
and usb host and regular ethernet and mmc and nand and oh crap, where
did all of my space go?).


I'm not saying this was directed to me (I'm sure it wasn't). Just to 
clarify my point: I'm really just trying to get the most basic SPL to 
work that loads U-Boot as FIT from spi-flash and verifies it. It might 
well be that it's this verified FIT offset that could be reduced...


Regards,
Simon

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

Am 08.01.2019 um 15:50 schrieb Marek Vasut:

On 1/8/19 3:48 PM, Tom Rini wrote:

On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:

On 1/8/19 1:46 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:


On 1/8/19 1:09 PM, Simon Goldschmidt wrote:

On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:


On 1/8/19 7:24 AM, Simon Goldschmidt wrote:

On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:


On 1/7/19 10:14 PM, Simon Goldschmidt wrote:

In order to build a smaller SPL, let's imply SPL_DM_RESET and
SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
via defconfig.

This also seems to be required to use OF_PLATDATA, as the reset drivers
don't seem to work with it.


How do you un-reset IP blocks if you disable the reset controller ?


Here again, socfpga seems to be another bad example. Taking
peripherals out of reset
is cluttered throughout the mach-socfpga code at least in SPL. By now
I know socfpga is
lacking support for clock and reset management via devicetree. And
this is bad, I know,
but can we keep this a seperate issue from OF_PLATDATA?

That being said, drivers/reset/reset-uclass.c fails to compile with
OF_PLATDATA, so I
guess this has not been used with OF_PLATDATA before. And given that I
don't seem
to need it for socfpga either, I don't think this would be the right
series to fix that.


Don't you need it to unreset at least the DWMMC or CQSPI ?


Reading the code, it seems like that's taken care of through another hack in
spl_boot_device() ;-)


Sigh.


Anyway, I'd much prefer to start cleaning up the horrorshow that
arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
Would that be possible ?


I would be best, yes. I don't know when I will find the time to do that, though.
I don't know how much effort that would be, either. Is there maybe a patch
where A10 got converted from "as bad as gen5" to its current state? That
would help me to see if I can do it...


A10 got switched to reset framework recently (in last 6 months or so),
the reset driver is the same for Gen5 and A10 too, so it should be easy
to recycle.


Hmm, ok, let me check that... it would indeed be nice to port this to gen5.

Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
to continue on this? I mean, I thought I heard people here saying "use
OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
keen on using it, either, but it does seem to give me some code space back...


OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
This platform has a massive 60k of SRAM for SPL, so if we're running out
of space, we're doing something wrong.


It's not for "30k or below" but "needs more space to enable all desired
features inside of SPL".


Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
bloated that even platform with so much space has issues, how can we
even cater for the rest of platforms with much more limited SPL ? And if
that is the case, we have a much bigger problem ...


I have to add here: I'm not running out of space in SPL just yet. I'm at 
45k But I have tried and the remaining 15k don't seem to be enough to 
add verified FIT loading code. I expect this to be something very rarely 
used, if it is used at all (I saw presentations doing this to implement 
verified boot, but I failed to find the code in SPL that does this)...


I don't know yet how I'll continue here. I'll check again exactly how 
much of the SRAM my current OF_PLATDATA patches save.


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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Tom Rini]

On Tue, Jan 08, 2019 at 03:50:48PM +0100, Marek Vasut wrote:
> On 1/8/19 3:48 PM, Tom Rini wrote:
> > On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> >> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> >>> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
> 
>  On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> >>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> 
>  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > In order to build a smaller SPL, let's imply SPL_DM_RESET and
> > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be 
> > disabled
> > via defconfig.
> >
> > This also seems to be required to use OF_PLATDATA, as the reset 
> > drivers
> > don't seem to work with it.
> 
>  How do you un-reset IP blocks if you disable the reset controller ?
> >>>
> >>> Here again, socfpga seems to be another bad example. Taking
> >>> peripherals out of reset
> >>> is cluttered throughout the mach-socfpga code at least in SPL. By now
> >>> I know socfpga is
> >>> lacking support for clock and reset management via devicetree. And
> >>> this is bad, I know,
> >>> but can we keep this a seperate issue from OF_PLATDATA?
> >>>
> >>> That being said, drivers/reset/reset-uclass.c fails to compile with
> >>> OF_PLATDATA, so I
> >>> guess this has not been used with OF_PLATDATA before. And given that I
> >>> don't seem
> >>> to need it for socfpga either, I don't think this would be the right
> >>> series to fix that.
> >>
> >> Don't you need it to unreset at least the DWMMC or CQSPI ?
> >
> > Reading the code, it seems like that's taken care of through another 
> > hack in
> > spl_boot_device() ;-)
> 
>  Sigh.
> 
> >> Anyway, I'd much prefer to start cleaning up the horrorshow that
> >> arch/arm/mach-socfpga is in terms of clock and reset, at least like 
> >> A10.
> >> Would that be possible ?
> >
> > I would be best, yes. I don't know when I will find the time to do 
> > that, though.
> > I don't know how much effort that would be, either. Is there maybe a 
> > patch
> > where A10 got converted from "as bad as gen5" to its current state? That
> > would help me to see if I can do it...
> 
>  A10 got switched to reset framework recently (in last 6 months or so),
>  the reset driver is the same for Gen5 and A10 too, so it should be easy
>  to recycle.
> >>>
> >>> Hmm, ok, let me check that... it would indeed be nice to port this to 
> >>> gen5.
> >>>
> >>> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> >>> to continue on this? I mean, I thought I heard people here saying "use
> >>> OF_PLATDATA" if you're running out of space in SPL. After using it, I'm 
> >>> not too
> >>> keen on using it, either, but it does seem to give me some code space 
> >>> back...
> >>
> >> OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
> >> This platform has a massive 60k of SRAM for SPL, so if we're running out
> >> of space, we're doing something wrong.
> > 
> > It's not for "30k or below" but "needs more space to enable all desired
> > features inside of SPL".
> 
> Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
> bloated that even platform with so much space has issues, how can we
> even cater for the rest of platforms with much more limited SPL ? And if
> that is the case, we have a much bigger problem ...

It depends, greatly, on what features you want within a single binary.
I'm not saying SoCFPGA can't fit what it wants, including verified boot,
inside of 60k.  But what I am saying is we don't have a hard-and-fast
limit on when you must not use OF_PLATDATA since it's always been easy
to make SPL too big, once you start including all of the possible
kitchen sink options (lets do falcon mode, and boot count and usb gadget
and usb host and regular ethernet and mmc and nand and oh crap, where
did all of my space go?).

-- 
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] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 3:48 PM, Tom Rini wrote:
> On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
>> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:

 On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:

 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be 
> disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the reset 
> drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset controller ?
>>>
>>> Here again, socfpga seems to be another bad example. Taking
>>> peripherals out of reset
>>> is cluttered throughout the mach-socfpga code at least in SPL. By now
>>> I know socfpga is
>>> lacking support for clock and reset management via devicetree. And
>>> this is bad, I know,
>>> but can we keep this a seperate issue from OF_PLATDATA?
>>>
>>> That being said, drivers/reset/reset-uclass.c fails to compile with
>>> OF_PLATDATA, so I
>>> guess this has not been used with OF_PLATDATA before. And given that I
>>> don't seem
>>> to need it for socfpga either, I don't think this would be the right
>>> series to fix that.
>>
>> Don't you need it to unreset at least the DWMMC or CQSPI ?
>
> Reading the code, it seems like that's taken care of through another hack 
> in
> spl_boot_device() ;-)

 Sigh.

>> Anyway, I'd much prefer to start cleaning up the horrorshow that
>> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
>> Would that be possible ?
>
> I would be best, yes. I don't know when I will find the time to do that, 
> though.
> I don't know how much effort that would be, either. Is there maybe a patch
> where A10 got converted from "as bad as gen5" to its current state? That
> would help me to see if I can do it...

 A10 got switched to reset framework recently (in last 6 months or so),
 the reset driver is the same for Gen5 and A10 too, so it should be easy
 to recycle.
>>>
>>> Hmm, ok, let me check that... it would indeed be nice to port this to gen5.
>>>
>>> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
>>> to continue on this? I mean, I thought I heard people here saying "use
>>> OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not 
>>> too
>>> keen on using it, either, but it does seem to give me some code space 
>>> back...
>>
>> OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
>> This platform has a massive 60k of SRAM for SPL, so if we're running out
>> of space, we're doing something wrong.
> 
> It's not for "30k or below" but "needs more space to enable all desired
> features inside of SPL".

Which the SoCFPGA should have with 60k of SRAM. If U-Boot SPL became so
bloated that even platform with so much space has issues, how can we
even cater for the rest of platforms with much more limited SPL ? And if
that is the case, we have a much bigger problem ...

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Tom Rini]

On Tue, Jan 08, 2019 at 01:49:14PM +0100, Marek Vasut wrote:
> On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> >>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
> 
>  On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be 
> >>> disabled
> >>> via defconfig.
> >>>
> >>> This also seems to be required to use OF_PLATDATA, as the reset 
> >>> drivers
> >>> don't seem to work with it.
> >>
> >> How do you un-reset IP blocks if you disable the reset controller ?
> >
> > Here again, socfpga seems to be another bad example. Taking
> > peripherals out of reset
> > is cluttered throughout the mach-socfpga code at least in SPL. By now
> > I know socfpga is
> > lacking support for clock and reset management via devicetree. And
> > this is bad, I know,
> > but can we keep this a seperate issue from OF_PLATDATA?
> >
> > That being said, drivers/reset/reset-uclass.c fails to compile with
> > OF_PLATDATA, so I
> > guess this has not been used with OF_PLATDATA before. And given that I
> > don't seem
> > to need it for socfpga either, I don't think this would be the right
> > series to fix that.
> 
>  Don't you need it to unreset at least the DWMMC or CQSPI ?
> >>>
> >>> Reading the code, it seems like that's taken care of through another hack 
> >>> in
> >>> spl_boot_device() ;-)
> >>
> >> Sigh.
> >>
>  Anyway, I'd much prefer to start cleaning up the horrorshow that
>  arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
>  Would that be possible ?
> >>>
> >>> I would be best, yes. I don't know when I will find the time to do that, 
> >>> though.
> >>> I don't know how much effort that would be, either. Is there maybe a patch
> >>> where A10 got converted from "as bad as gen5" to its current state? That
> >>> would help me to see if I can do it...
> >>
> >> A10 got switched to reset framework recently (in last 6 months or so),
> >> the reset driver is the same for Gen5 and A10 too, so it should be easy
> >> to recycle.
> > 
> > Hmm, ok, let me check that... it would indeed be nice to port this to gen5.
> > 
> > Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> > to continue on this? I mean, I thought I heard people here saying "use
> > OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not 
> > too
> > keen on using it, either, but it does seem to give me some code space 
> > back...
> 
> OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
> This platform has a massive 60k of SRAM for SPL, so if we're running out
> of space, we're doing something wrong.

It's not for "30k or below" but "needs more space to enable all desired
features inside of SPL".

-- 
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] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Marek Vasut]

On 1/8/19 2:51 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 2:38 PM Marek Vasut  wrote:
>>
>> On 1/8/19 2:07 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut  wrote:

 On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:

 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
>
> There are two motivations for this:
> a) reduce code size to eventually support secure boot (where SPL has 
> to
>authenticate the next stage by loading/checking U-Boot from a FIT
>image)
> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
>(on warm-restart), all bytes to check need to be in one piece. With
>OF_SEPARATE, this is not the case (.bss is between .rodata and the
>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
>be a good solution.

 I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
 than having some ad-hoc plat data again if we can avoid that.
>>>
>>> So you're against the whole OF_PLATDATA thing or how should I understand
>>> that?
>>
>> If we can avoid it, I'd prefer to do so.
>>
>>> It's not really ad-hoc, it's the DT converted to C structs. It's just 
>>> in another
>>> format, but it's still (sort of) decoupled SW from HW.
>>>
>>> As written above, I have two goals I want to achieve with this. Right 
>>> now, I
>>> cannot enable verified boot in SPL because the available OCRAM cannot
>>> hold all the code. And it seemed to me OF_PLATDATA could help me there.
>>
>> Well this might be a long shot, but I discussed this lack of OCRAM
>> during 35C3 and there was a suggestion to lock L2 cache lines above ROM
>> (so there's some backing store) and use that as extra SRAM. Would that
>> help you ?
>
> I would have joined that discussion if my Family would have let me go 
> during the
> holidays :-))
>
> This is an interesing idea, but actually it's a lack of code/rodata
> size. The Intel
> docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB 
> at
> max. I have not checked the code size increase I would get when enabling 
> trusted
> boot (SPL loading U-Boot from FIT and verifying it with a public key),
> but I'm currently
> at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
> booting from SPI.
> When booting from MMC, the code is about ~4 KiB smaller but BSS grows to 
> ~600
> Bytes.

 I wonder if there are some huge chunks of code which could be optimized?

> Of course the stack and initial malloc area do need some bytes too, but I 
> think
> summed up, bss, stack and malloc should probably fit into 4 KiB, so I
> currently have
> about 15 KiB to add FIT loading and public key verification/hashing. I
> don't think that's
> enough just from the code size.
>
> And on socfpga, I think all added code would use the heap, which is
> changed to SDRAM
> very early, so it's not the RAM that is tight.

 Can you check readelf and see how the function size looks ? Maybe
 there's something which is just too big ?
>>>
>>> I'm looking at the map file all the time ;-) The only thing that looks
>>> too big is
>>> SDRAM initialization, which is about 16 KiB overall, I think. The rest
>>> just seems
>>> to be smaller parts. But the binary blob u32 arrays created by Quartus don't
>>> help, either: rodata is about 9 KiB.
>>
>> Can that be somehow optimized ? The ideal approach would be to move it
>> somehow to DT.
> 
> I don't know if those binary blobs (pin config, clock config etc.) can
> be converted
> without internal information from Intel.
> 
> The SDRAM initialization might just be bad code, I don't know.
> 
> So like you wrote in the other thread: obviously, we're doing something wrong
> as those 60 KiB will not be enough for what I want SPL to do. But, I haven't 
> yet
> found something that is just obviously code bloat.

I wonder if the SDRAM init tables aren't a bit sparse for example. Maybe
something can be done there ?

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

Re: [U-Boot] Please pull from u-boot-i2c

[Tom Rini]

On Tue, Jan 08, 2019 at 12:33:06PM +0100, Heiko Schocher wrote:
> Hello Tom,
> 
> please pull from u-boot-i2c.git master
> 
> The following changes since commit 53240275666acf32cb9811e44eaf2fd571a6cb75:
> 
>   Merge tag 'for-v2019.01' of git://git.denx.de/u-boot-video (2019-01-03 
> 15:34:44 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to 37b52c5a91c50c5e56f16d6a52c2835a3839a9e8:
> 
> 
>   i2c: i2c-cdns: Use proper input frequency (2019-01-07 11:23:47 +0100)
> 
> 
> Marek Vasut (1):
>   i2c: xiic: Add Xilinx AXI I2C driver
> 
> Tomasz Gorochowik (1):
>   i2c: i2c-cdns: Use proper input frequency
> 
>  drivers/i2c/Kconfig   |   6 +++
>  drivers/i2c/Makefile  |   1 +
>  drivers/i2c/i2c-cdns.c|   9 +++-
>  drivers/i2c/xilinx_xiic.c | 340 
> +
>  4 files changed, 355 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/i2c/xilinx_xiic.c
> 
> pull request content:
> 
> - new i2c driver posted from Marek:
>   Add Xilinx AXI I2C controller driver based on the Linux i2c-xiic driver
> 
> - i2c-cdns: Use proper input frequency
>   from Tomasz
> 
> travis build looks fine:
> 
> https://travis-ci.org/hsdenx/u-boot-i2c/builds/476314217

Why are we adding a new driver right now?  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] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Lukasz Majewski]

On Tue, 8 Jan 2019 14:37:49 +0100
Marek Vasut  wrote:

> On 1/8/19 2:06 PM, Jean-Jacques Hiblot wrote:
> > 
> > On 08/01/2019 13:47, Marek Vasut wrote:  
> >> On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:  
> >>> On 08/01/2019 12:18, Marek Vasut wrote:  
>  On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:  
> > This series applies on top of u-boot-dfu.
> >
> > This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
> > CONFIG_SPL_USB_GADGET
> > for consistency.
> > It also uses CONFIG_USB_GADGET to compile-in the gadget code.
> > This make
> > sure that the code is not included if it is not needed. Some
> > defconfigs
> > had to be updated as they relied on the gadget code to be always
> > compiled.
> >
> > TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900
> >
> > Jean-Jacques Hiblot (2):
> >     Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
> > CONFIG_SPL_USB_GADGET
> >     usb: Make compiling gadget support optional
> >
> >    Makefile | 4 ++--
> >    arch/arm/mach-imx/mx6/Kconfig    | 2 +-
> >    arch/arm/mach-imx/spl.c  | 2 +-
> >    common/spl/Kconfig   | 4 ++--
> >    configs/am335x_boneblack_vboot_defconfig | 2 +-
> >    configs/am335x_evm_usbspl_defconfig  | 2 +-
> >    configs/am43xx_evm_defconfig | 2 +-
> >    configs/am43xx_hs_evm_defconfig  | 2 +-
> >    configs/apalis_imx6_defconfig    | 2 +-
> >    configs/cm_t3517_defconfig   | 1 +
> >    configs/cm_t35_defconfig | 1 +
> >    configs/colibri_imx6_defconfig   | 2 +-
> >    configs/display5_factory_defconfig   | 2 +-
> >    configs/duovero_defconfig    | 1 +
> >    configs/igep0032_defconfig   | 1 +
> >    configs/igep00x0_defconfig   | 1 +
> >    configs/imx6q_logic_defconfig    | 2 +-
> >    configs/mx6memcal_defconfig  | 2 +-
> >    configs/mx6sabresd_defconfig | 2 +-
> >    configs/omap3_zoom1_defconfig    | 1 +
> >    configs/omap4_panda_defconfig    | 1 +
> >    configs/omap4_sdp4430_defconfig  | 1 +
> >    configs/pico-hobbit-imx6ul_defconfig | 2 +-
> >    configs/pico-hobbit-imx7d_defconfig  | 2 +-
> >    configs/pico-imx6ul_defconfig    | 2 +-
> >    configs/pico-imx7d_defconfig | 2 +-
> >    configs/pico-pi-imx6ul_defconfig | 2 +-
> >    configs/pico-pi-imx7d_defconfig  | 2 +-
> >    configs/spear300_usbtty_defconfig    | 2 ++
> >    configs/spear300_usbtty_nand_defconfig   | 2 ++
> >    configs/spear310_usbtty_defconfig    | 2 ++
> >    configs/spear310_usbtty_nand_defconfig   | 2 ++
> >    configs/spear310_usbtty_pnor_defconfig   | 2 ++
> >    configs/spear320_usbtty_defconfig    | 2 ++
> >    configs/spear320_usbtty_nand_defconfig   | 2 ++
> >    configs/spear320_usbtty_pnor_defconfig   | 2 ++
> >    configs/spear600_usbtty_defconfig    | 2 ++
> >    configs/spear600_usbtty_nand_defconfig   | 2 ++
> >    drivers/Makefile | 6 +++---
> >    drivers/usb/gadget/Makefile  | 2 +-
> >    scripts/Makefile.spl | 2 +-
> >    41 files changed, 55 insertions(+), 27 deletions(-)
> >  
>  I'll let Lukasz handle integrating this. Does it get rid of the
>  patch I complained about in the PR ? I hope so ..  
> >>> I applies on top of u-boot-dfu and fixes the issue you complained
> >>> about.
> >>>
> >>> It doesn't get rid of the patch per se but rather is a
> >>> complement.  
> >> Can they be squashed together somehow ?  
> > 
> > IMO they make more sense as separate patches. but I see no problem
> > if Lukasz wants to squash them.  
> 
> I'd prefer to replace the broken patch.
> 
> 

The patch to be replaced/amended is:
dm: usb: gadget: Fix boot breakage on sunxi platforms

I'm fine with adding those two patches on top of it. 

Or do I miss something?


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpz4YxBBxG_l.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] pylibfdt: Use Python 2 in Makefile

[Josef Lusticky]

pylibfdt needs Python 2 to build.
Replace $(PYTHON) with $(PYTHON2) in pylibfdt Makefile
to ensure Python 2 is used to build it.

This fixes build on systems where Python 3 is the default version
of the "python" interpreter.
---
 scripts/dtc/pylibfdt/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/dtc/pylibfdt/Makefile b/scripts/dtc/pylibfdt/Makefile
index c769d7db06..15e66ad44d 100644
--- a/scripts/dtc/pylibfdt/Makefile
+++ b/scripts/dtc/pylibfdt/Makefile
@@ -21,7 +21,7 @@ quiet_cmd_pymod = PYMOD   $@
CPPFLAGS="$(HOSTCFLAGS) -I$(LIBFDT_srcdir)" OBJDIR=$(obj) \
SOURCES="$(PYLIBFDT_srcs)" \
SWIG_OPTS="-I$(LIBFDT_srcdir) -I$(LIBFDT_srcdir)/.." \
-   $(PYTHON) $< --quiet build_ext --inplace
+   $(PYTHON2) $< --quiet build_ext --inplace
 
 $(obj)/_libfdt.so: $(src)/setup.py $(PYLIBFDT_srcs) FORCE
$(call if_changed,pymod)
-- 
2.20.1

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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Marek Vasut]

On 1/8/19 2:06 PM, Jean-Jacques Hiblot wrote:
> 
> On 08/01/2019 13:47, Marek Vasut wrote:
>> On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:
>>> On 08/01/2019 12:18, Marek Vasut wrote:
 On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:
> This series applies on top of u-boot-dfu.
>
> This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
> CONFIG_SPL_USB_GADGET
> for consistency.
> It also uses CONFIG_USB_GADGET to compile-in the gadget code. This
> make
> sure that the code is not included if it is not needed. Some
> defconfigs
> had to be updated as they relied on the gadget code to be always
> compiled.
>
> TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900
>
> Jean-Jacques Hiblot (2):
>     Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
> CONFIG_SPL_USB_GADGET
>     usb: Make compiling gadget support optional
>
>    Makefile | 4 ++--
>    arch/arm/mach-imx/mx6/Kconfig    | 2 +-
>    arch/arm/mach-imx/spl.c  | 2 +-
>    common/spl/Kconfig   | 4 ++--
>    configs/am335x_boneblack_vboot_defconfig | 2 +-
>    configs/am335x_evm_usbspl_defconfig  | 2 +-
>    configs/am43xx_evm_defconfig | 2 +-
>    configs/am43xx_hs_evm_defconfig  | 2 +-
>    configs/apalis_imx6_defconfig    | 2 +-
>    configs/cm_t3517_defconfig   | 1 +
>    configs/cm_t35_defconfig | 1 +
>    configs/colibri_imx6_defconfig   | 2 +-
>    configs/display5_factory_defconfig   | 2 +-
>    configs/duovero_defconfig    | 1 +
>    configs/igep0032_defconfig   | 1 +
>    configs/igep00x0_defconfig   | 1 +
>    configs/imx6q_logic_defconfig    | 2 +-
>    configs/mx6memcal_defconfig  | 2 +-
>    configs/mx6sabresd_defconfig | 2 +-
>    configs/omap3_zoom1_defconfig    | 1 +
>    configs/omap4_panda_defconfig    | 1 +
>    configs/omap4_sdp4430_defconfig  | 1 +
>    configs/pico-hobbit-imx6ul_defconfig | 2 +-
>    configs/pico-hobbit-imx7d_defconfig  | 2 +-
>    configs/pico-imx6ul_defconfig    | 2 +-
>    configs/pico-imx7d_defconfig | 2 +-
>    configs/pico-pi-imx6ul_defconfig | 2 +-
>    configs/pico-pi-imx7d_defconfig  | 2 +-
>    configs/spear300_usbtty_defconfig    | 2 ++
>    configs/spear300_usbtty_nand_defconfig   | 2 ++
>    configs/spear310_usbtty_defconfig    | 2 ++
>    configs/spear310_usbtty_nand_defconfig   | 2 ++
>    configs/spear310_usbtty_pnor_defconfig   | 2 ++
>    configs/spear320_usbtty_defconfig    | 2 ++
>    configs/spear320_usbtty_nand_defconfig   | 2 ++
>    configs/spear320_usbtty_pnor_defconfig   | 2 ++
>    configs/spear600_usbtty_defconfig    | 2 ++
>    configs/spear600_usbtty_nand_defconfig   | 2 ++
>    drivers/Makefile | 6 +++---
>    drivers/usb/gadget/Makefile  | 2 +-
>    scripts/Makefile.spl | 2 +-
>    41 files changed, 55 insertions(+), 27 deletions(-)
>
 I'll let Lukasz handle integrating this. Does it get rid of the patch I
 complained about in the PR ? I hope so ..
>>> I applies on top of u-boot-dfu and fixes the issue you complained about.
>>>
>>> It doesn't get rid of the patch per se but rather is a complement.
>> Can they be squashed together somehow ?
> 
> IMO they make more sense as separate patches. but I see no problem if
> Lukasz wants to squash them.

I'd prefer to replace the broken patch.


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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Marek Vasut]

On 1/8/19 2:57 PM, Lukasz Majewski wrote:
> On Tue, 8 Jan 2019 14:37:49 +0100
> Marek Vasut  wrote:
> 
>> On 1/8/19 2:06 PM, Jean-Jacques Hiblot wrote:
>>>
>>> On 08/01/2019 13:47, Marek Vasut wrote:  
 On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:  
> On 08/01/2019 12:18, Marek Vasut wrote:  
>> On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:  
>>> This series applies on top of u-boot-dfu.
>>>
>>> This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
>>> CONFIG_SPL_USB_GADGET
>>> for consistency.
>>> It also uses CONFIG_USB_GADGET to compile-in the gadget code.
>>> This make
>>> sure that the code is not included if it is not needed. Some
>>> defconfigs
>>> had to be updated as they relied on the gadget code to be always
>>> compiled.
>>>
>>> TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900
>>>
>>> Jean-Jacques Hiblot (2):
>>>     Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
>>> CONFIG_SPL_USB_GADGET
>>>     usb: Make compiling gadget support optional
>>>
>>>    Makefile | 4 ++--
>>>    arch/arm/mach-imx/mx6/Kconfig    | 2 +-
>>>    arch/arm/mach-imx/spl.c  | 2 +-
>>>    common/spl/Kconfig   | 4 ++--
>>>    configs/am335x_boneblack_vboot_defconfig | 2 +-
>>>    configs/am335x_evm_usbspl_defconfig  | 2 +-
>>>    configs/am43xx_evm_defconfig | 2 +-
>>>    configs/am43xx_hs_evm_defconfig  | 2 +-
>>>    configs/apalis_imx6_defconfig    | 2 +-
>>>    configs/cm_t3517_defconfig   | 1 +
>>>    configs/cm_t35_defconfig | 1 +
>>>    configs/colibri_imx6_defconfig   | 2 +-
>>>    configs/display5_factory_defconfig   | 2 +-
>>>    configs/duovero_defconfig    | 1 +
>>>    configs/igep0032_defconfig   | 1 +
>>>    configs/igep00x0_defconfig   | 1 +
>>>    configs/imx6q_logic_defconfig    | 2 +-
>>>    configs/mx6memcal_defconfig  | 2 +-
>>>    configs/mx6sabresd_defconfig | 2 +-
>>>    configs/omap3_zoom1_defconfig    | 1 +
>>>    configs/omap4_panda_defconfig    | 1 +
>>>    configs/omap4_sdp4430_defconfig  | 1 +
>>>    configs/pico-hobbit-imx6ul_defconfig | 2 +-
>>>    configs/pico-hobbit-imx7d_defconfig  | 2 +-
>>>    configs/pico-imx6ul_defconfig    | 2 +-
>>>    configs/pico-imx7d_defconfig | 2 +-
>>>    configs/pico-pi-imx6ul_defconfig | 2 +-
>>>    configs/pico-pi-imx7d_defconfig  | 2 +-
>>>    configs/spear300_usbtty_defconfig    | 2 ++
>>>    configs/spear300_usbtty_nand_defconfig   | 2 ++
>>>    configs/spear310_usbtty_defconfig    | 2 ++
>>>    configs/spear310_usbtty_nand_defconfig   | 2 ++
>>>    configs/spear310_usbtty_pnor_defconfig   | 2 ++
>>>    configs/spear320_usbtty_defconfig    | 2 ++
>>>    configs/spear320_usbtty_nand_defconfig   | 2 ++
>>>    configs/spear320_usbtty_pnor_defconfig   | 2 ++
>>>    configs/spear600_usbtty_defconfig    | 2 ++
>>>    configs/spear600_usbtty_nand_defconfig   | 2 ++
>>>    drivers/Makefile | 6 +++---
>>>    drivers/usb/gadget/Makefile  | 2 +-
>>>    scripts/Makefile.spl | 2 +-
>>>    41 files changed, 55 insertions(+), 27 deletions(-)
>>>  
>> I'll let Lukasz handle integrating this. Does it get rid of the
>> patch I complained about in the PR ? I hope so ..  
> I applies on top of u-boot-dfu and fixes the issue you complained
> about.
>
> It doesn't get rid of the patch per se but rather is a
> complement.  
 Can they be squashed together somehow ?  
>>>
>>> IMO they make more sense as separate patches. but I see no problem
>>> if Lukasz wants to squash them.  
>>
>> I'd prefer to replace the broken patch.
>>
>>
> 
> The patch to be replaced/amended is:
> dm: usb: gadget: Fix boot breakage on sunxi platforms
> 
> I'm fine with adding those two patches on top of it. 
> 
> Or do I miss something?

I don't want broken patches in the tree if it can be avoided, which in
this case is still possible.

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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Marek Vasut]

On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:
> 
> On 08/01/2019 12:18, Marek Vasut wrote:
>> On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:
>>> This series applies on top of u-boot-dfu.
>>>
>>> This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
>>> CONFIG_SPL_USB_GADGET
>>> for consistency.
>>> It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
>>> sure that the code is not included if it is not needed. Some defconfigs
>>> had to be updated as they relied on the gadget code to be always
>>> compiled.
>>>
>>> TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900
>>>
>>> Jean-Jacques Hiblot (2):
>>>    Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
>>> CONFIG_SPL_USB_GADGET
>>>    usb: Make compiling gadget support optional
>>>
>>>   Makefile | 4 ++--
>>>   arch/arm/mach-imx/mx6/Kconfig    | 2 +-
>>>   arch/arm/mach-imx/spl.c  | 2 +-
>>>   common/spl/Kconfig   | 4 ++--
>>>   configs/am335x_boneblack_vboot_defconfig | 2 +-
>>>   configs/am335x_evm_usbspl_defconfig  | 2 +-
>>>   configs/am43xx_evm_defconfig | 2 +-
>>>   configs/am43xx_hs_evm_defconfig  | 2 +-
>>>   configs/apalis_imx6_defconfig    | 2 +-
>>>   configs/cm_t3517_defconfig   | 1 +
>>>   configs/cm_t35_defconfig | 1 +
>>>   configs/colibri_imx6_defconfig   | 2 +-
>>>   configs/display5_factory_defconfig   | 2 +-
>>>   configs/duovero_defconfig    | 1 +
>>>   configs/igep0032_defconfig   | 1 +
>>>   configs/igep00x0_defconfig   | 1 +
>>>   configs/imx6q_logic_defconfig    | 2 +-
>>>   configs/mx6memcal_defconfig  | 2 +-
>>>   configs/mx6sabresd_defconfig | 2 +-
>>>   configs/omap3_zoom1_defconfig    | 1 +
>>>   configs/omap4_panda_defconfig    | 1 +
>>>   configs/omap4_sdp4430_defconfig  | 1 +
>>>   configs/pico-hobbit-imx6ul_defconfig | 2 +-
>>>   configs/pico-hobbit-imx7d_defconfig  | 2 +-
>>>   configs/pico-imx6ul_defconfig    | 2 +-
>>>   configs/pico-imx7d_defconfig | 2 +-
>>>   configs/pico-pi-imx6ul_defconfig | 2 +-
>>>   configs/pico-pi-imx7d_defconfig  | 2 +-
>>>   configs/spear300_usbtty_defconfig    | 2 ++
>>>   configs/spear300_usbtty_nand_defconfig   | 2 ++
>>>   configs/spear310_usbtty_defconfig    | 2 ++
>>>   configs/spear310_usbtty_nand_defconfig   | 2 ++
>>>   configs/spear310_usbtty_pnor_defconfig   | 2 ++
>>>   configs/spear320_usbtty_defconfig    | 2 ++
>>>   configs/spear320_usbtty_nand_defconfig   | 2 ++
>>>   configs/spear320_usbtty_pnor_defconfig   | 2 ++
>>>   configs/spear600_usbtty_defconfig    | 2 ++
>>>   configs/spear600_usbtty_nand_defconfig   | 2 ++
>>>   drivers/Makefile | 6 +++---
>>>   drivers/usb/gadget/Makefile  | 2 +-
>>>   scripts/Makefile.spl | 2 +-
>>>   41 files changed, 55 insertions(+), 27 deletions(-)
>>>
>> I'll let Lukasz handle integrating this. Does it get rid of the patch I
>> complained about in the PR ? I hope so ..
> 
> I applies on top of u-boot-dfu and fixes the issue you complained about.
> 
> It doesn't get rid of the patch per se but rather is a complement.

Can they be squashed together somehow ?

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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Jean-Jacques Hiblot]

On 08/01/2019 13:47, Marek Vasut wrote:

On 1/8/19 1:43 PM, Jean-Jacques Hiblot wrote:

On 08/01/2019 12:18, Marek Vasut wrote:

On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:

This series applies on top of u-boot-dfu.

This series renames CONFIG_SPL_USB_GADGET_SUPPORT to
CONFIG_SPL_USB_GADGET
for consistency.
It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
sure that the code is not included if it is not needed. Some defconfigs
had to be updated as they relied on the gadget code to be always
compiled.

TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900

Jean-Jacques Hiblot (2):
    Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as
CONFIG_SPL_USB_GADGET
    usb: Make compiling gadget support optional

   Makefile | 4 ++--
   arch/arm/mach-imx/mx6/Kconfig    | 2 +-
   arch/arm/mach-imx/spl.c  | 2 +-
   common/spl/Kconfig   | 4 ++--
   configs/am335x_boneblack_vboot_defconfig | 2 +-
   configs/am335x_evm_usbspl_defconfig  | 2 +-
   configs/am43xx_evm_defconfig | 2 +-
   configs/am43xx_hs_evm_defconfig  | 2 +-
   configs/apalis_imx6_defconfig    | 2 +-
   configs/cm_t3517_defconfig   | 1 +
   configs/cm_t35_defconfig | 1 +
   configs/colibri_imx6_defconfig   | 2 +-
   configs/display5_factory_defconfig   | 2 +-
   configs/duovero_defconfig    | 1 +
   configs/igep0032_defconfig   | 1 +
   configs/igep00x0_defconfig   | 1 +
   configs/imx6q_logic_defconfig    | 2 +-
   configs/mx6memcal_defconfig  | 2 +-
   configs/mx6sabresd_defconfig | 2 +-
   configs/omap3_zoom1_defconfig    | 1 +
   configs/omap4_panda_defconfig    | 1 +
   configs/omap4_sdp4430_defconfig  | 1 +
   configs/pico-hobbit-imx6ul_defconfig | 2 +-
   configs/pico-hobbit-imx7d_defconfig  | 2 +-
   configs/pico-imx6ul_defconfig    | 2 +-
   configs/pico-imx7d_defconfig | 2 +-
   configs/pico-pi-imx6ul_defconfig | 2 +-
   configs/pico-pi-imx7d_defconfig  | 2 +-
   configs/spear300_usbtty_defconfig    | 2 ++
   configs/spear300_usbtty_nand_defconfig   | 2 ++
   configs/spear310_usbtty_defconfig    | 2 ++
   configs/spear310_usbtty_nand_defconfig   | 2 ++
   configs/spear310_usbtty_pnor_defconfig   | 2 ++
   configs/spear320_usbtty_defconfig    | 2 ++
   configs/spear320_usbtty_nand_defconfig   | 2 ++
   configs/spear320_usbtty_pnor_defconfig   | 2 ++
   configs/spear600_usbtty_defconfig    | 2 ++
   configs/spear600_usbtty_nand_defconfig   | 2 ++
   drivers/Makefile | 6 +++---
   drivers/usb/gadget/Makefile  | 2 +-
   scripts/Makefile.spl | 2 +-
   41 files changed, 55 insertions(+), 27 deletions(-)


I'll let Lukasz handle integrating this. Does it get rid of the patch I
complained about in the PR ? I hope so ..

I applies on top of u-boot-dfu and fixes the issue you complained about.

It doesn't get rid of the patch per se but rather is a complement.

Can they be squashed together somehow ?


IMO they make more sense as separate patches. but I see no problem if 
Lukasz wants to squash them.





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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Jean-Jacques Hiblot]

On 08/01/2019 12:18, Marek Vasut wrote:

On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:

This series applies on top of u-boot-dfu.

This series renames CONFIG_SPL_USB_GADGET_SUPPORT to CONFIG_SPL_USB_GADGET
for consistency.
It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
sure that the code is not included if it is not needed. Some defconfigs
had to be updated as they relied on the gadget code to be always compiled.

TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900

Jean-Jacques Hiblot (2):
   Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET
   usb: Make compiling gadget support optional

  Makefile | 4 ++--
  arch/arm/mach-imx/mx6/Kconfig| 2 +-
  arch/arm/mach-imx/spl.c  | 2 +-
  common/spl/Kconfig   | 4 ++--
  configs/am335x_boneblack_vboot_defconfig | 2 +-
  configs/am335x_evm_usbspl_defconfig  | 2 +-
  configs/am43xx_evm_defconfig | 2 +-
  configs/am43xx_hs_evm_defconfig  | 2 +-
  configs/apalis_imx6_defconfig| 2 +-
  configs/cm_t3517_defconfig   | 1 +
  configs/cm_t35_defconfig | 1 +
  configs/colibri_imx6_defconfig   | 2 +-
  configs/display5_factory_defconfig   | 2 +-
  configs/duovero_defconfig| 1 +
  configs/igep0032_defconfig   | 1 +
  configs/igep00x0_defconfig   | 1 +
  configs/imx6q_logic_defconfig| 2 +-
  configs/mx6memcal_defconfig  | 2 +-
  configs/mx6sabresd_defconfig | 2 +-
  configs/omap3_zoom1_defconfig| 1 +
  configs/omap4_panda_defconfig| 1 +
  configs/omap4_sdp4430_defconfig  | 1 +
  configs/pico-hobbit-imx6ul_defconfig | 2 +-
  configs/pico-hobbit-imx7d_defconfig  | 2 +-
  configs/pico-imx6ul_defconfig| 2 +-
  configs/pico-imx7d_defconfig | 2 +-
  configs/pico-pi-imx6ul_defconfig | 2 +-
  configs/pico-pi-imx7d_defconfig  | 2 +-
  configs/spear300_usbtty_defconfig| 2 ++
  configs/spear300_usbtty_nand_defconfig   | 2 ++
  configs/spear310_usbtty_defconfig| 2 ++
  configs/spear310_usbtty_nand_defconfig   | 2 ++
  configs/spear310_usbtty_pnor_defconfig   | 2 ++
  configs/spear320_usbtty_defconfig| 2 ++
  configs/spear320_usbtty_nand_defconfig   | 2 ++
  configs/spear320_usbtty_pnor_defconfig   | 2 ++
  configs/spear600_usbtty_defconfig| 2 ++
  configs/spear600_usbtty_nand_defconfig   | 2 ++
  drivers/Makefile | 6 +++---
  drivers/usb/gadget/Makefile  | 2 +-
  scripts/Makefile.spl | 2 +-
  41 files changed, 55 insertions(+), 27 deletions(-)


I'll let Lukasz handle integrating this. Does it get rid of the patch I
complained about in the PR ? I hope so ..


I applies on top of u-boot-dfu and fixes the issue you complained about.

It doesn't get rid of the patch per se but rather is a complement.




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

[U-Boot] [PATCH] arm64: zynqmp: Fix tcminit help text alignment

[Michal Simek]

Trivial patch.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/cmds.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/board/xilinx/zynqmp/cmds.c b/board/xilinx/zynqmp/cmds.c
index 3e039ccb13ea..321670d4e3ea 100644
--- a/board/xilinx/zynqmp/cmds.c
+++ b/board/xilinx/zynqmp/cmds.c
@@ -174,11 +174,11 @@ static char zynqmp_help_text[] =
"zynqmp mmio_write address mask value - write value after masking to\n"
"   address\n"
 #ifdef CONFIG_DEFINE_TCM_OCM_MMAP
-   "zynqmp tcminit  mode - Initialize the TCM with zeros. TCM needs to 
be\n"
-   "   initialized before accessing to avoid ECC\n"
-   "   errors. mode specifies in which mode TCM has\n"
-   "   to be initialized. Supported modes will be\n"
-   "   lock(0)/split(1)\n"
+   "zynqmp tcminit mode - Initialize the TCM with zeros. TCM needs to be\n"
+   "  initialized before accessing to avoid ECC\n"
+   "  errors. mode specifies in which mode TCM has\n"
+   "  to be initialized. Supported modes will be\n"
+   "  lock(0)/split(1)\n"
 #endif
;
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH v1 2/2] x86: edison: Switch to CONFIG_OF_SEPARATE

[Andy Shevchenko]

There is no need for Intel Edison to have CONFIG_OF_EMBED to be enabled.
Replace it with CONFIG_OF_SEPARATE.

There is no functional change since u-boot.bin always contains DTB
either embedded or attached.

Signed-off-by: Andy Shevchenko 
---
 configs/edison_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/edison_defconfig b/configs/edison_defconfig
index e376c0cea6..dc7d86aafe 100644
--- a/configs/edison_defconfig
+++ b/configs/edison_defconfig
@@ -26,7 +26,7 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_EMBED=y
+CONFIG_OF_SEPARATE=y
 CONFIG_DEFAULT_DEVICE_TREE="edison"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_CPU=y
-- 
2.19.2

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

[U-Boot] [PATCH v1 1/2] doc: Fix CONFIG_OF_SEPARATE description

[Andy Shevchenko]

CONFIG_OF_SEPARATE description is not in align with actual code in Makefile and
thus has misleading instructions and explanation.

Make it aligned with the actual code.

Signed-off-by: Andy Shevchenko 
---
 doc/README.fdt-control | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/README.fdt-control b/doc/README.fdt-control
index 446401c9e9..e53cf51875 100644
--- a/doc/README.fdt-control
+++ b/doc/README.fdt-control
@@ -122,13 +122,14 @@ the U-Boot image (including u-boot.bin). This is suitable 
for debugging
 and development only and is not recommended for production devices.
 
 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
-a u-boot.dtb file alongside u-boot.bin. A common approach is then to
+a u-boot.dtb file alongside u-boot-nodtb.bin. A common approach is then to
 join the two:
 
-   cat u-boot.bin u-boot.dtb >image.bin
+   cat u-boot-nodtb.bin u-boot.dtb >image.bin
 
 and then flash image.bin onto your board. Note that U-Boot creates
-u-boot-dtb.bin which does the above step for you also. If you are using
+u-boot-dtb.bin which does the above step for you also. Resulting
+u-boot.bin is a copy of u-boot-dtb.bin in this case. If you are using
 CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
-- 
2.19.2

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

[U-Boot] [PATCH v3] xyz-modem: Fix timeout loop waiting with WATCHDOG

[Lokesh Vutla]

Commit 2c77c0d6524eb ("xyz-modem: Change getc timeout loop waiting")
fixes the loop delay when using a hw watchdog, assuming that watchdog
kicking is taken care of by getc(). But the xyzmodem driver tries to
do a getc only after confirming that a character is available like below:
while (!tstc()) {
till timeout;
}
if (tstc())
*c = getc();

and getc() does a watchdog reset only if it fails to see a character.
In this case, getc() always sees a character and never does a
watchdog reset. So to make sure that watchdog doesn't get reset
while loading the file, do a watchdog reset just before starting the
image loading.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Vignesh R 
---
- This fixes uart boot on am335x-evm.
Changes since v2:
- Updated commit message.

 common/xyzModem.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/xyzModem.c b/common/xyzModem.c
index e5c65b480a..e85da74a69 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Assumption - run xyzModem protocol over the console port */
 
@@ -63,6 +64,7 @@ CYGACC_COMM_IF_GETC_TIMEOUT (char chan, char *c)
 {
 
   ulong now = get_timer(0);
+  WATCHDOG_RESET();
   while (!tstc ())
 {
   if (get_timer(now) > xyzModem_CHAR_TIMEOUT)
-- 
2.19.2

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

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 2:38 PM Marek Vasut  wrote:
>
> On 1/8/19 2:07 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
> >>> On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:
> 
>  On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >>>
> >>> There are two motivations for this:
> >>> a) reduce code size to eventually support secure boot (where SPL has 
> >>> to
> >>>authenticate the next stage by loading/checking U-Boot from a FIT
> >>>image)
> >>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >>>(on warm-restart), all bytes to check need to be in one piece. With
> >>>OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >>>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >>>be a good solution.
> >>
> >> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
> >> than having some ad-hoc plat data again if we can avoid that.
> >
> > So you're against the whole OF_PLATDATA thing or how should I understand
> > that?
> 
>  If we can avoid it, I'd prefer to do so.
> 
> > It's not really ad-hoc, it's the DT converted to C structs. It's just 
> > in another
> > format, but it's still (sort of) decoupled SW from HW.
> >
> > As written above, I have two goals I want to achieve with this. Right 
> > now, I
> > cannot enable verified boot in SPL because the available OCRAM cannot
> > hold all the code. And it seemed to me OF_PLATDATA could help me there.
> 
>  Well this might be a long shot, but I discussed this lack of OCRAM
>  during 35C3 and there was a suggestion to lock L2 cache lines above ROM
>  (so there's some backing store) and use that as extra SRAM. Would that
>  help you ?
> >>>
> >>> I would have joined that discussion if my Family would have let me go 
> >>> during the
> >>> holidays :-))
> >>>
> >>> This is an interesing idea, but actually it's a lack of code/rodata
> >>> size. The Intel
> >>> docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB 
> >>> at
> >>> max. I have not checked the code size increase I would get when enabling 
> >>> trusted
> >>> boot (SPL loading U-Boot from FIT and verifying it with a public key),
> >>> but I'm currently
> >>> at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
> >>> booting from SPI.
> >>> When booting from MMC, the code is about ~4 KiB smaller but BSS grows to 
> >>> ~600
> >>> Bytes.
> >>
> >> I wonder if there are some huge chunks of code which could be optimized?
> >>
> >>> Of course the stack and initial malloc area do need some bytes too, but I 
> >>> think
> >>> summed up, bss, stack and malloc should probably fit into 4 KiB, so I
> >>> currently have
> >>> about 15 KiB to add FIT loading and public key verification/hashing. I
> >>> don't think that's
> >>> enough just from the code size.
> >>>
> >>> And on socfpga, I think all added code would use the heap, which is
> >>> changed to SDRAM
> >>> very early, so it's not the RAM that is tight.
> >>
> >> Can you check readelf and see how the function size looks ? Maybe
> >> there's something which is just too big ?
> >
> > I'm looking at the map file all the time ;-) The only thing that looks
> > too big is
> > SDRAM initialization, which is about 16 KiB overall, I think. The rest
> > just seems
> > to be smaller parts. But the binary blob u32 arrays created by Quartus don't
> > help, either: rodata is about 9 KiB.
>
> Can that be somehow optimized ? The ideal approach would be to move it
> somehow to DT.

I don't know if those binary blobs (pin config, clock config etc.) can
be converted
without internal information from Intel.

The SDRAM initialization might just be bad code, I don't know.

So like you wrote in the other thread: obviously, we're doing something wrong
as those 60 KiB will not be enough for what I want SPL to do. But, I haven't yet
found something that is just obviously code bloat.

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

Re: [U-Boot] Bogus message about SCSI during build

[Andy Shevchenko]

On Tue, Jan 8, 2019 at 3:04 AM Bin Meng  wrote:
> On Tue, Jan 8, 2019 at 2:38 AM Andy Shevchenko
>  wrote:
> > On Mon, Jan 7, 2019 at 8:34 PM Andy Shevchenko
> >  wrote:

> > > The platform does have DM_MMC and BLK as far as I can see, other than
> > > that I have no idea how CONFIG_DM_SCSI becomes set.
> > > Something broken upper, not on this certain board.
> >
> > config X86
> > ...
> > imply DM_SCSI
> > ...
> >
> > This has to be fixed, not my board. Message now is bogus.
> >
>
> No. SCSI is common for almost all x86 boards, hence we use 'imply'.

Which is good and not a problem per se.

> And we acknowledge that some boards may not have it so we don't use
> 'select'.  You can turn it off in your board defconfig.

No, the board shouldn't care about some architecture defaults and
those defaults should be carefully chosen in the first place.
Nevertheless, I like the Tom's patch which fixes the actual problem.

-- 
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Marek Vasut]

On 1/8/19 2:07 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut  wrote:
>>
>> On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:

 On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
>>>
>>> There are two motivations for this:
>>> a) reduce code size to eventually support secure boot (where SPL has to
>>>authenticate the next stage by loading/checking U-Boot from a FIT
>>>image)
>>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
>>>(on warm-restart), all bytes to check need to be in one piece. With
>>>OF_SEPARATE, this is not the case (.bss is between .rodata and the
>>>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
>>>be a good solution.
>>
>> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
>> than having some ad-hoc plat data again if we can avoid that.
>
> So you're against the whole OF_PLATDATA thing or how should I understand
> that?

 If we can avoid it, I'd prefer to do so.

> It's not really ad-hoc, it's the DT converted to C structs. It's just in 
> another
> format, but it's still (sort of) decoupled SW from HW.
>
> As written above, I have two goals I want to achieve with this. Right 
> now, I
> cannot enable verified boot in SPL because the available OCRAM cannot
> hold all the code. And it seemed to me OF_PLATDATA could help me there.

 Well this might be a long shot, but I discussed this lack of OCRAM
 during 35C3 and there was a suggestion to lock L2 cache lines above ROM
 (so there's some backing store) and use that as extra SRAM. Would that
 help you ?
>>>
>>> I would have joined that discussion if my Family would have let me go 
>>> during the
>>> holidays :-))
>>>
>>> This is an interesing idea, but actually it's a lack of code/rodata
>>> size. The Intel
>>> docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB at
>>> max. I have not checked the code size increase I would get when enabling 
>>> trusted
>>> boot (SPL loading U-Boot from FIT and verifying it with a public key),
>>> but I'm currently
>>> at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
>>> booting from SPI.
>>> When booting from MMC, the code is about ~4 KiB smaller but BSS grows to 
>>> ~600
>>> Bytes.
>>
>> I wonder if there are some huge chunks of code which could be optimized?
>>
>>> Of course the stack and initial malloc area do need some bytes too, but I 
>>> think
>>> summed up, bss, stack and malloc should probably fit into 4 KiB, so I
>>> currently have
>>> about 15 KiB to add FIT loading and public key verification/hashing. I
>>> don't think that's
>>> enough just from the code size.
>>>
>>> And on socfpga, I think all added code would use the heap, which is
>>> changed to SDRAM
>>> very early, so it's not the RAM that is tight.
>>
>> Can you check readelf and see how the function size looks ? Maybe
>> there's something which is just too big ?
> 
> I'm looking at the map file all the time ;-) The only thing that looks
> too big is
> SDRAM initialization, which is about 16 KiB overall, I think. The rest
> just seems
> to be smaller parts. But the binary blob u32 arrays created by Quartus don't
> help, either: rodata is about 9 KiB.

Can that be somehow optimized ? The ideal approach would be to move it
somehow to DT.

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

Re: [U-Boot] [PATCH 1/1] efi_loader: refactor switch to non-secure mode

[Alexander Graf]

On 30.12.18 15:36, Heinrich Schuchardt wrote:
> Refactor the switch from supervisor to hypervisor to a new function called
> at the beginning of do_bootefi().
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v3
>   Move weak function to common/bootm.c.
>   Rename functions.
>   Add more comments.
>   Avoid static variable for jump buffer.
> v2
>   Use weak function with implementation in arch directories
> ---
>  arch/arm/cpu/armv7/Makefile  |  1 +
>  arch/arm/cpu/armv7/exception_level.c | 56 ++
>  arch/arm/cpu/armv8/Makefile  |  1 +
>  arch/arm/cpu/armv8/exception_level.c | 55 +
>  cmd/bootefi.c| 72 ++--
>  common/bootm.c   | 10 
>  include/bootm.h  |  5 ++
>  7 files changed, 132 insertions(+), 68 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/exception_level.c
>  create mode 100644 arch/arm/cpu/armv8/exception_level.c
> 
> diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
> index 4f4647c90ac..8c955d0d528 100644
> --- a/arch/arm/cpu/armv7/Makefile
> +++ b/arch/arm/cpu/armv7/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_SYS_ARM_MPU) += mpu_v7r.o
>  
>  ifneq ($(CONFIG_SPL_BUILD),y)
>  obj-$(CONFIG_EFI_LOADER) += sctlr.o
> +obj-$(CONFIG_ARMV7_NONSEC) += exception_level.o
>  endif
>  
>  ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
> diff --git a/arch/arm/cpu/armv7/exception_level.c 
> b/arch/arm/cpu/armv7/exception_level.c
> new file mode 100644
> index 000..e116435623f
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/exception_level.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Switch to non-secure mode
> + *
> + * Copyright (c) 2018 Heinrich Schuchardt
> + *
> + * This module contains the ARMv7 specific code required for leaving the
> + * secure mode before booting an operating system.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * entry_non_secure() - entry point when switching to non-secure mode
> + *
> + * When switching to non-secure mode switch_to_non_secure_mode() calls this
> + * function passing a jump buffer. We use this jump buffer to restoring the

... to restore ...

> + * original stack and register state.
> + *
> + * @non_secure_jmp:  jump buffer for restoring stack and registers
> + */
> +static void entry_non_secure(struct jmp_buf_data *non_secure_jmp)
> +{
> + dcache_enable();
> + debug("Reached non-secure mode\n");
> +
> + /* Restore stack and registers saved in switch_to_non_secure_mode() */
> + longjmp(non_secure_jmp, 1);
> +}
> +
> +/**
> + * switch_to_non_secure_mode() - switch to non-secure mode
> + *
> + * Operating systems are expected to run in non-secure mode. Here we check if

This is not 100% correct. They are not always expected to be executed in
NS mode. This depends on CONFIG_ARMV7_BOOT_SEC_DEFAULT as well as
bootm_boot_mode (in your code even).

So better word this as "Operating Systems may expect to run".

> + * we are running in secure mode and switch to non-secure mode if necessary.
> + */
> +void switch_to_non_secure_mode(void)
> +{
> + static bool is_nonsec;
> + struct jmp_buf_data non_secure_jmp;
> +
> + if (armv7_boot_nonsec() && !is_nonsec) {
> + if (setjmp(_secure_jmp))
> + return;
> + dcache_disable();   /* flush cache before switch to HYP */
> + armv7_init_nonsec();
> + is_nonsec = true;
> + secure_ram_addr(_do_nonsec_entry)(entry_non_secure,
> +   (uintptr_t)_secure_jmp,
> +   0, 0);
> + }
> +}
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index 52c8daa0496..8b0b887a696 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -14,6 +14,7 @@ ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) += exceptions.o
>  else
>  obj-y+= exceptions.o
> +obj-y   += exception_level.o

Please use a tab here.

>  endif
>  obj-y+= cache.o
>  obj-y+= tlb.o
> diff --git a/arch/arm/cpu/armv8/exception_level.c 
> b/arch/arm/cpu/armv8/exception_level.c
> new file mode 100644
> index 000..245af3f1d4e
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/exception_level.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Switch to non-secure mode
> + *
> + * Copyright (c) 2018 Heinrich Schuchardt
> + *
> + * This module contains the ARMv8 specific code required to adjust the 
> exception
> + * level before booting an operating system.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * entry_non_secure() - entry point when switching to non-secure mode
> + *
> + * When switching to non-secure mode switch_to_non_secure_mode() calls this
> + * function passing a jump buffer. We use this jump buffer to 

Re: [U-Boot] [PATCH] Makefile: Correct logic for DM_SCSI + unconverted drivers check

[Andy Shevchenko]

On Tue, Jan 8, 2019 at 5:58 AM Tom Rini  wrote:
>
> When checking for boards that are enabling a SATA driver that isn't
> converted to DM yet we need to be sure to not also trip over boards that
> do set CONFIG_DM_SCSI by itself, as that is not a bug.
>

Thanks!
It fixes a bogus message,
Tested-by: Andy Shevchenko 



> Reported-by: Andy Shevchenko 
> Fixes: ea9d7c17fc4c ("dm: MIGRATION: Add migration plan for CONFIG_SATA")
> Signed-off-by: Tom Rini 
> ---
>  Makefile | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 27c09199a446..e3e54a393f68 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -938,7 +938,8 @@ ifneq 
> ($(CONFIG_DM_USB)$(CONFIG_OF_CONTROL)$(CONFIG_BLK),yyy)
> @echo >&2 ""
>  endif
>  endif
> -ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y)
> +ifeq ($(CONFIG_LIBATA)$(CONFIG_MVSATA_IDE),y)
> +ifneq ($(CONFIG_DM_SCSI),y)
> @echo >&2 "= WARNING =="
> @echo >&2 "This board does not use CONFIG_DM_SCSI. Please update"
> @echo >&2 "the storage controller to use CONFIG_DM_SCSI before the 
> v2019.07 release."
> @@ -946,6 +947,7 @@ ifeq 
> ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y)
> @echo >&2 "See doc/driver-model/MIGRATION.txt for more info."
> @echo >&2 ""
>  endif
> +endif
>  ifeq ($(CONFIG_OF_EMBED),y)
> @echo >&2 "= WARNING =="
> @echo >&2 "CONFIG_OF_EMBED is enabled. This option should only"
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: Enable CONFIG_BLK in a few TI boards

[Lokesh Vutla]

+ Tom

On 08/01/19 6:16 PM, Faiz Abbas wrote:
> With DM conversion completed, enable CONFIG_BLK for a
> few pending TI boards.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  configs/am335x_boneblack_vboot_defconfig  | 1 -
>  configs/am335x_evm_defconfig  | 1 -
>  configs/am335x_hs_evm_defconfig   | 1 -
>  configs/am335x_hs_evm_uart_defconfig  | 1 -
>  configs/am43xx_evm_defconfig  | 1 -
>  configs/am43xx_evm_qspiboot_defconfig | 1 -
>  configs/am43xx_evm_rtconly_defconfig  | 1 -
>  configs/am43xx_evm_usbhost_boot_defconfig | 1 -
>  configs/am43xx_hs_evm_defconfig   | 1 -
>  configs/am57xx_evm_defconfig  | 1 -
>  configs/am57xx_hs_evm_defconfig   | 1 -
>  configs/k2g_evm_defconfig | 1 -
>  configs/k2g_hs_evm_defconfig  | 1 -
>  13 files changed, 13 deletions(-)
> 
> diff --git a/configs/am335x_boneblack_vboot_defconfig 
> b/configs/am335x_boneblack_vboot_defconfig
> index c62e8322fb..093a9b1c8e 100644
> --- a/configs/am335x_boneblack_vboot_defconfig
> +++ b/configs/am335x_boneblack_vboot_defconfig
> @@ -29,7 +29,6 @@ CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -# CONFIG_BLK is not set
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index 0931c1e97f..a0951b05ee 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -26,7 +26,6 @@ CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
>  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> am335x-bonegreen am335x-icev2"
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -# CONFIG_BLK is not set
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_NAND=y
> diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
> index 1a7c5cfb17..4de09f8bab 100644
> --- a/configs/am335x_hs_evm_defconfig
> +++ b/configs/am335x_hs_evm_defconfig
> @@ -32,7 +32,6 @@ CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
>  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> am335x-bonegreen am335x-icev2"
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -# CONFIG_BLK is not set
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_NAND=y
> diff --git a/configs/am335x_hs_evm_uart_defconfig 
> b/configs/am335x_hs_evm_uart_defconfig
> index 147da80f0d..3613c7023d 100644
> --- a/configs/am335x_hs_evm_uart_defconfig
> +++ b/configs/am335x_hs_evm_uart_defconfig
> @@ -34,7 +34,6 @@ CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
>  CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
> am335x-bonegreen am335x-icev2"
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> -# CONFIG_BLK is not set
>  CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_NAND=y
> diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
> index 481aa4fad9..d58c9c1a25 100644
> --- a/configs/am43xx_evm_defconfig
> +++ b/configs/am43xx_evm_defconfig
> @@ -36,7 +36,6 @@ CONFIG_REGMAP=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_SYSCON=y
>  CONFIG_SPL_SYSCON=y
> -# CONFIG_BLK is not set
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
>  CONFIG_DFU_SF=y
> diff --git a/configs/am43xx_evm_qspiboot_defconfig 
> b/configs/am43xx_evm_qspiboot_defconfig
> index 0d7bd72157..9dd67f6c44 100644
> --- a/configs/am43xx_evm_qspiboot_defconfig
> +++ b/configs/am43xx_evm_qspiboot_defconfig
> @@ -31,7 +31,6 @@ CONFIG_MULTI_DTB_FIT=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> -# CONFIG_BLK is not set
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
>  CONFIG_DFU_SF=y
> diff --git a/configs/am43xx_evm_rtconly_defconfig 
> b/configs/am43xx_evm_rtconly_defconfig
> index 7d56db43fd..1448262ba2 100644
> --- a/configs/am43xx_evm_rtconly_defconfig
> +++ b/configs/am43xx_evm_rtconly_defconfig
> @@ -28,7 +28,6 @@ CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
>  CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> -# CONFIG_BLK is not set
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
>  CONFIG_DFU_SF=y
> diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
> b/configs/am43xx_evm_usbhost_boot_defconfig
> index 5131f190a7..6e90bd02c6 100644
> --- a/configs/am43xx_evm_usbhost_boot_defconfig
> +++ b/configs/am43xx_evm_usbhost_boot_defconfig
> @@ -40,7 +40,6 @@ CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm 
> am437x-idk-evm"
>  CONFIG_ENV_IS_IN_FAT=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> -# CONFIG_BLK is not set
>  CONFIG_DFU_MMC=y
>  CONFIG_DFU_RAM=y
>  CONFIG_DFU_SF=y
> diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
> index 5d98e0edee..bff6f0a401 100644
> --- a/configs/am43xx_hs_evm_defconfig
> 

Re: [U-Boot] [PATCH 8/8] arm: imx7s-warp: Convert to DM PMIC

[Peng Fan]

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Stefano Babic 
> Subject: [PATCH 8/8] arm: imx7s-warp: Convert to DM PMIC
> 
> This patch converts the warp7 and warp7_bl33 board ports over to using the
> DM PMIC model.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  board/warp7/warp7.c  | 27 +++
>  configs/warp7_bl33_defconfig |  6 ++
>  configs/warp7_defconfig  |  6 ++
>  include/configs/warp7.h  |  6 --
>  4 files changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index
> 19f0df4d09..6ebeb08e33 100644
> --- a/board/warp7/warp7.c
> +++ b/board/warp7/warp7.c
> @@ -64,29 +64,24 @@ int board_early_init_f(void)
>   return 0;
>  }
> 
> -#ifdef CONFIG_POWER
> -#define I2C_PMIC   0
> -static struct pmic *pfuze;
> +#ifdef CONFIG_DM_PMIC
>  int power_init_board(void)
>  {
> - int ret;
> - unsigned int reg, rev_id;
> + struct udevice *dev;
> + int ret, dev_id, rev_id;
> 
> - ret = power_pfuze3000_init(I2C_PMIC);
> - if (ret)
> + ret = pmic_get("pfuze3000", );
> + if (ret == -ENODEV)
> + return 0;
> + if (ret != 0)
>   return ret;
> 
> - pfuze = pmic_get("PFUZE3000");
> - ret = pmic_probe(pfuze);
> - if (ret)
> - return ret;
> -
> - pmic_reg_read(pfuze, PFUZE3000_DEVICEID, );
> - pmic_reg_read(pfuze, PFUZE3000_REVID, _id);
> - printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id);
> + dev_id = pmic_reg_read(dev, PFUZE3000_DEVICEID);
> + rev_id = pmic_reg_read(dev, PFUZE3000_REVID);
> + printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", dev_id,
> rev_id);
> 
>   /* disable Low Power Mode during standby mode */
> - pmic_reg_write(pfuze, PFUZE3000_LDOGCTL, 0x1);
> + pmic_clrsetbits(dev, PFUZE3000_LDOGCTL, 0, 1);
> 
>   return 0;
>  }
> diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
> index 2e80011cbc..7b40bfbd6d 100644
> --- a/configs/warp7_bl33_defconfig
> +++ b/configs/warp7_bl33_defconfig
> @@ -45,3 +45,9 @@ CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_IMX7=y
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
> +CONFIG_DM_PMIC=y
> +CONFIG_DM_PMIC_PFUZE100=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_PFUZE100=y
> +CONFIG_DM_REGULATOR_FIXED=y
> +CONFIG_DM_REGULATOR_GPIO=y
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> 9f7dc73a11..d1c8e403a7 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -58,3 +58,9 @@ CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_IMX7=y
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
> +CONFIG_DM_PMIC=y
> +CONFIG_DM_PMIC_PFUZE100=y
> +CONFIG_DM_REGULATOR=y
> +CONFIG_DM_REGULATOR_PFUZE100=y
> +CONFIG_DM_REGULATOR_FIXED=y
> +CONFIG_DM_REGULATOR_GPIO=y
> diff --git a/include/configs/warp7.h b/include/configs/warp7.h index
> 41eb8d7e1d..043f2861b6 100644
> --- a/include/configs/warp7.h
> +++ b/include/configs/warp7.h
> @@ -129,12 +129,6 @@
>  #define CONFIG_SYS_I2C_MXC
>  #define CONFIG_SYS_I2C_SPEED 10
> 
> -/* PMIC */
> -#define CONFIG_POWER
> -#define CONFIG_POWER_I2C
> -#define CONFIG_POWER_PFUZE3000
> -#define CONFIG_POWER_PFUZE3000_I2C_ADDR  0x08
> -
>  /* environment organization */
>  #define CONFIG_ENV_SIZE  SZ_8K
> 

Reviewed-by: Peng Fan 

> --
> 2.20.0

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

Re: [U-Boot] [PATCH 7/8] warp7: defconfig: Switch to DM for I2C

[Peng Fan]

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Stefano Babic 
> Subject: [PATCH 7/8] warp7: defconfig: Switch to DM for I2C
> 
> This commit switches to DM I2C for warp7 and warp7_bl33 defconfigs.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  board/warp7/warp7.c  | 24 
>  configs/warp7_bl33_defconfig |  1 +
>  configs/warp7_defconfig  |  1 +
>  include/configs/warp7.h  |  2 --
>  4 files changed, 2 insertions(+), 26 deletions(-)
> 
> diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index
> 146d722b15..19f0df4d09 100644
> --- a/board/warp7/warp7.c
> +++ b/board/warp7/warp7.c
> @@ -31,26 +31,6 @@ DECLARE_GLOBAL_DATA_PTR;  #define
> UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM |
> PAD_CTL_PUS_PU100KOHM | \
>   PAD_CTL_HYS)
> 
> -#define I2C_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM |
> PAD_CTL_SRE_SLOW | \
> - PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM)
> -
> -#ifdef CONFIG_SYS_I2C_MXC
> -#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> -/* I2C1 for PMIC */
> -static struct i2c_pads_info i2c_pad_info1 = {
> - .scl = {
> - .i2c_mode = MX7D_PAD_I2C1_SCL__I2C1_SCL | PC,
> - .gpio_mode = MX7D_PAD_I2C1_SCL__GPIO4_IO8 | PC,
> - .gp = IMX_GPIO_NR(4, 8),
> - },
> - .sda = {
> - .i2c_mode = MX7D_PAD_I2C1_SDA__I2C1_SDA | PC,
> - .gpio_mode = MX7D_PAD_I2C1_SDA__GPIO4_IO9 | PC,
> - .gp = IMX_GPIO_NR(4, 9),
> - },
> -};
> -#endif
> -
>  int dram_init(void)
>  {
>   gd->ram_size = PHYS_SDRAM_SIZE;
> @@ -130,10 +110,6 @@ int board_init(void)
>   /* address of boot parameters */
>   gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> 
> - #ifdef CONFIG_SYS_I2C_MXC
> - setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
> - #endif
> -
>   return 0;
>  }
> 
> diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
> index 7f21bb4f53..2e80011cbc 100644
> --- a/configs/warp7_bl33_defconfig
> +++ b/configs/warp7_bl33_defconfig
> @@ -44,3 +44,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_IMX7=y
>  CONFIG_DM_GPIO=y
> +CONFIG_DM_I2C=y
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> 2d3171e42a..9f7dc73a11 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -57,3 +57,4 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
>  CONFIG_PINCTRL=y
>  CONFIG_PINCTRL_IMX7=y
>  CONFIG_DM_GPIO=y
> +CONFIG_DM_I2C=y
> diff --git a/include/configs/warp7.h b/include/configs/warp7.h index
> a391dfb5c1..41eb8d7e1d 100644
> --- a/include/configs/warp7.h
> +++ b/include/configs/warp7.h
> @@ -126,9 +126,7 @@
>   (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
> 
>  /* I2C configs */
> -#define CONFIG_SYS_I2C
>  #define CONFIG_SYS_I2C_MXC
> -#define CONFIG_SYS_I2C_MXC_I2C1
>  #define CONFIG_SYS_I2C_SPEED 10
> 

Reviewed-by: Peng Fan 

>  /* PMIC */
> --
> 2.20.0

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

Re: [U-Boot] [PATCH 5/8] warp7: defconfig: Switch on IMX7 pinctrl for both ports

[Peng Fan]

> 
> 
> > -Original Message-
> > From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> > Sent: 2019年1月3日 9:45
> > To: u-boot@lists.denx.de
> > Cc: Fabio Estevam ; Peng Fan
> > ; Bryan O'Donoghue ;
> > Stefano Babic 
> > Subject: [PATCH 5/8] warp7: defconfig: Switch on IMX7 pinctrl for both
> > ports
> >
> > Switches on the IMX7 pinctrl driver for the warp7 and warp7_bl33
> > ports, necessary to convert over to DM for this board.
> >
> > Signed-off-by: Bryan O'Donoghue 
> > Cc: Peng Fan 
> > Cc: Fabio Estevam 
> > Cc: Stefano Babic 
> > ---
> >  configs/warp7_bl33_defconfig | 2 ++
> >  configs/warp7_defconfig  | 2 ++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/configs/warp7_bl33_defconfig
> > b/configs/warp7_bl33_defconfig index b2f943c775..a2c2555315 100644
> > --- a/configs/warp7_bl33_defconfig
> > +++ b/configs/warp7_bl33_defconfig
> > @@ -41,3 +41,5 @@ CONFIG_USB_ETH_CDC=y
> > CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
> >  CONFIG_OPTEE_TZDRAM_SIZE=0x200
> >  CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
> > +CONFIG_PINCTRL=y
> > +CONFIG_PINCTRL_IMX7=y
> > diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> > 65d801ffe2..8691d00491 100644
> > --- a/configs/warp7_defconfig
> > +++ b/configs/warp7_defconfig
> > @@ -54,3 +54,5 @@ CONFIG_OPTEE_TZDRAM_SIZE=0x300
> >  CONFIG_OPTEE_TZDRAM_BASE=0x9d00
> >  CONFIG_BOOTM_OPTEE=y
> >  CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
> > +CONFIG_PINCTRL=y
> > +CONFIG_PINCTRL_IMX7=y
> 
> Reviewed-by: Peng Fan 

Just have a follow up question,
in patch 4/8, DM MMC is enabled, but in 5/8 pinctrl DM is enabled.
This might be not correct, the DM MMC/PINCTRL/GPIO needs to be in one patch.
The fsl_esdhc DM support does not support DM MMC with legacy iomux code.

Regards,
Peng.
> 
> > --
> > 2.20.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7CPeng.Fan%40nxp.co
> m%7Cf6fbfc5331eb4328683308d6756c7489%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636825506006750873sdata=iXlXGGewCrW%
> 2B4srkP4d%2BWnZ7UX2AyCK8Tgx93g3SpF8%3Dreserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/8] warp7: defconfig: Switch on IMX7 pinctrl for both ports

[Peng Fan]

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Stefano Babic 
> Subject: [PATCH 5/8] warp7: defconfig: Switch on IMX7 pinctrl for both ports
> 
> Switches on the IMX7 pinctrl driver for the warp7 and warp7_bl33 ports,
> necessary to convert over to DM for this board.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  configs/warp7_bl33_defconfig | 2 ++
>  configs/warp7_defconfig  | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
> index b2f943c775..a2c2555315 100644
> --- a/configs/warp7_bl33_defconfig
> +++ b/configs/warp7_bl33_defconfig
> @@ -41,3 +41,5 @@ CONFIG_USB_ETH_CDC=y
>  CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
>  CONFIG_OPTEE_TZDRAM_SIZE=0x200
>  CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_IMX7=y
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> 65d801ffe2..8691d00491 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -54,3 +54,5 @@ CONFIG_OPTEE_TZDRAM_SIZE=0x300
>  CONFIG_OPTEE_TZDRAM_BASE=0x9d00
>  CONFIG_BOOTM_OPTEE=y
>  CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_IMX7=y

Reviewed-by: Peng Fan 

> --
> 2.20.0

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

Re: [U-Boot] [PATCH 3/8] arm: imx7s-warp: Convert to DM MMC initialization

[Peng Fan]

Hi Bryan,

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Albert Aribaud ; Stefano Babic
> 
> Subject: [PATCH 3/8] arm: imx7s-warp: Convert to DM MMC initialization
> 
> Converts from fixed initialization of MMC to DM initialization of MMC.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Albert Aribaud 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/imx7s-warp.dts  | 11 ---
>  board/warp7/warp7.c  | 34 --
>  configs/warp7_bl33_defconfig |  1 +
>  configs/warp7_defconfig  |  1 +
>  4 files changed, 2 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
> index c44db20734..615ed7ed80 100644
> --- a/arch/arm/dts/imx7s-warp.dts
> +++ b/arch/arm/dts/imx7s-warp.dts
> @@ -251,17 +251,6 @@
>   status = "okay";
>  };
> 
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_usdhc1>;
> - bus-width = <4>;
> - keep-power-in-suspend;
> - no-1-8-v;
> - non-removable;
> - vmmc-supply = <_brcm>;
> - status = "okay";
> -};
> -

Why drop this node? Seems this is for SDIO wifi, Is there any issue if keep 
this node?

Regards,
Peng.

>   {
>   pinctrl-names = "default", "state_100mhz", "state_200mhz";
>   pinctrl-0 = <_usdhc3>;
> diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c index
> 3d32b3eb52..146d722b15 100644
> --- a/board/warp7/warp7.c
> +++ b/board/warp7/warp7.c
> @@ -30,8 +30,6 @@ DECLARE_GLOBAL_DATA_PTR;
> 
>  #define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM |
> PAD_CTL_PUS_PU100KOHM | \
>   PAD_CTL_HYS)
> -#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM |
> PAD_CTL_SRE_SLOW |\
> - PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
> 
>  #define I2C_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM |
> PAD_CTL_SRE_SLOW | \
>   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU100KOHM) @@
> -74,43 +72,11 @@ static iomux_v3_cfg_t const uart1_pads[] = {
>   MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX |
> MUX_PAD_CTRL(UART_PAD_CTRL),  };
> 
> -static iomux_v3_cfg_t const usdhc3_pads[] = {
> - MX7D_PAD_SD3_CLK__SD3_CLK |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_CMD__SD3_CMD |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA0__SD3_DATA0 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA1__SD3_DATA1 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA2__SD3_DATA2 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA3__SD3_DATA3 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA4__SD3_DATA4 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA5__SD3_DATA5 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA6__SD3_DATA6 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_DATA7__SD3_DATA7 |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> - MX7D_PAD_SD3_RESET_B__SD3_RESET_B |
> MUX_PAD_CTRL(USDHC_PAD_CTRL),
> -};
> -
>  static void setup_iomux_uart(void)
>  {
>   imx_iomux_v3_setup_multiple_pads(uart1_pads,
> ARRAY_SIZE(uart1_pads));  };
> 
> -static struct fsl_esdhc_cfg usdhc_cfg[1] = {
> - {USDHC3_BASE_ADDR},
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - /* Assume uSDHC3 emmc is always present */
> - return 1;
> -}
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - imx_iomux_v3_setup_multiple_pads(usdhc3_pads,
> ARRAY_SIZE(usdhc3_pads));
> - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> -
> - return fsl_esdhc_initialize(bis, _cfg[0]);
> -}
> -
>  int board_early_init_f(void)
>  {
>   setup_iomux_uart();
> diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
> index 12141fedd3..b2f943c775 100644
> --- a/configs/warp7_bl33_defconfig
> +++ b/configs/warp7_bl33_defconfig
> @@ -24,6 +24,7 @@ CONFIG_OF_CONTROL=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DFU_MMC=y
> +CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> fee98dfbbe..65d801ffe2 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -33,6 +33,7 @@ CONFIG_OF_CONTROL=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DFU_MMC=y
> +CONFIG_DM_MMC=y
>  CONFIG_FSL_ESDHC=y
>  CONFIG_OPTEE=y
>  CONFIG_USB=y
> --
> 2.20.0

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

Re: [U-Boot] [PATCH 2/8] arm: imx7s-warp: Add DT file hooks

[Peng Fan]

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Albert Aribaud ; Stefano Babic
> 
> Subject: [PATCH 2/8] arm: imx7s-warp: Add DT file hooks
> 
> This patch adds DT file hooks for imx7s-warp.dtb to the warp7 and
> warp7_bl33 builds.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Albert Aribaud 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/Makefile| 3 ++-
>  configs/warp7_bl33_defconfig | 3 ++-
>  configs/warp7_defconfig  | 3 ++-
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> dda4e59491..4fe7e90902 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -460,7 +460,8 @@ dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
> 
>  dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
>   imx7d-sdb.dtb \
> - imx7d-sdb-qspi.dtb
> + imx7d-sdb-qspi.dtb \
> + imx7s-warp.dtb
> 
>  dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
> 
> diff --git a/configs/warp7_bl33_defconfig b/configs/warp7_bl33_defconfig
> index a568c6d10e..12141fedd3 100644
> --- a/configs/warp7_bl33_defconfig
> +++ b/configs/warp7_bl33_defconfig
> @@ -20,6 +20,7 @@ CONFIG_CMD_EXT2=y
>  CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
> +CONFIG_OF_CONTROL=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DFU_MMC=y
> @@ -37,5 +38,5 @@ CONFIG_USB_GADGET_DOWNLOAD=y
> CONFIG_USB_ETHER=y  CONFIG_USB_ETH_CDC=y
> CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
> -CONFIG_OF_LIBFDT=y
>  CONFIG_OPTEE_TZDRAM_SIZE=0x200
> +CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"
> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index
> 4d443295ba..fee98dfbbe 100644
> --- a/configs/warp7_defconfig
> +++ b/configs/warp7_defconfig
> @@ -29,6 +29,7 @@ CONFIG_CMD_EXT2=y
>  CONFIG_CMD_EXT4=y
>  CONFIG_CMD_EXT4_WRITE=y
>  CONFIG_CMD_FAT=y
> +CONFIG_OF_CONTROL=y
>  CONFIG_CMD_FS_GENERIC=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_DFU_MMC=y
> @@ -47,8 +48,8 @@ CONFIG_USB_GADGET_DOWNLOAD=y
> CONFIG_USB_ETHER=y  CONFIG_USB_ETH_CDC=y
> CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
> -CONFIG_OF_LIBFDT=y
>  CONFIG_OPTEE_LOAD_ADDR=0x8400
>  CONFIG_OPTEE_TZDRAM_SIZE=0x300
>  CONFIG_OPTEE_TZDRAM_BASE=0x9d00
>  CONFIG_BOOTM_OPTEE=y
> +CONFIG_DEFAULT_DEVICE_TREE="imx7s-warp"

Reviewed-by: Peng Fan 

> --
> 2.20.0

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

Re: [U-Boot] [PATCH 1/8] arm: dts: imx7s-warp: Import Linux warp7 dts

[Peng Fan]

Hi Bryan,

> -Original Message-
> From: Bryan O'Donoghue [mailto:bryan.odonog...@linaro.org]
> Sent: 2019年1月3日 9:45
> To: u-boot@lists.denx.de
> Cc: Fabio Estevam ; Peng Fan
> ; Bryan O'Donoghue ;
> Albert Aribaud ; Stefano Babic
> 
> Subject: [PATCH 1/8] arm: dts: imx7s-warp: Import Linux warp7 dts
> 
> This patch imports the Linux kernel warp7 dts as at upstream kernel commit
> cf76c364a1e1.
> 
> The following was dropped from the incoming kernel DTS file

U-Boot dts synced from Linux Kernel DTS file. If there is issue, it should be 
fixed in Linux side and imported to U-Boot.

Regards,
Peng

> 
> - {
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_wdog>;
> -   fsl,ext-reset-output;
> -   status = "okay";
> -};
> -
> -
> -_lpsr {
> -   pinctrl_wdog: wdoggrp {
> -   fsl,pins = <
> -
> MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B  0x74
> -   >;
> -   };
> -};
> 
> it causes a DTC compile error for me and isn't needed for u-boot in any case.
> 
> Signed-off-by: Bryan O'Donoghue 
> Cc: Albert Aribaud 
> Cc: Peng Fan 
> Cc: Fabio Estevam 
> Cc: Stefano Babic 
> ---
>  arch/arm/dts/imx7s-warp.dts | 423
> 
>  1 file changed, 423 insertions(+)
>  create mode 100644 arch/arm/dts/imx7s-warp.dts
> 
> diff --git a/arch/arm/dts/imx7s-warp.dts b/arch/arm/dts/imx7s-warp.dts
> new file mode 100644 index 00..c44db20734
> --- /dev/null
> +++ b/arch/arm/dts/imx7s-warp.dts
> @@ -0,0 +1,423 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2016 NXP Semiconductors.
> + * Author: Fabio Estevam   */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "imx7s.dtsi"
> +
> +/ {
> + model = "Warp i.MX7 Board";
> + compatible = "warp,imx7s-warp", "fsl,imx7s";
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>;
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-0 = <_gpio>;
> + autorepeat;
> +
> + back {
> + label = "Back";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + linux,code = ;
> + wakeup-source;
> + };
> + };
> +
> + reg_brcm: regulator-brcm {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = < 10 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_brcm_reg>;
> + regulator-name = "brcm_reg";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + startup-delay-us = <20>;
> + };
> +
> + reg_bt: regulator-bt {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <_bt_reg>;
> + enable-active-high;
> + gpio = < 17 GPIO_ACTIVE_HIGH>;
> + regulator-name = "bt_reg";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "imx7-sgtl5000";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,bitclock-master = <_master>;
> + simple-audio-card,frame-master = <_master>;
> + simple-audio-card,cpu {
> + sound-dai = <>;
> + };
> +
> + dailink_master: simple-audio-card,codec {
> + sound-dai = <>;
> + clocks = < IMX7D_AUDIO_MCLK_ROOT_CLK>;
> + };
> + };
> +};
> +
> + {
> + assigned-clocks = < IMX7D_PLL_AUDIO_POST_DIV>;
> + assigned-clock-rates = <884736000>;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c1>;
> + status = "okay";
> +
> + pmic: pfuze3000@8 {
> + compatible = "fsl,pfuze3000";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1a {
> + regulator-min-microvolt = <70>;
> + regulator-max-microvolt = <1475000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + /* use sw1c_reg to align with pfuze100/pfuze200 */
> + sw1c_reg: sw1b {
> + regulator-min-microvolt = <70>;
> + regulator-max-microvolt = <1475000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + 

Re: [U-Boot] [PATCH 2/5] efi_loader: set entry point in efi_load_pe()

[Alexander Graf]

On 28.12.18 12:41, Heinrich Schuchardt wrote:
> Up to now efi_load_pe() returns the entry point or NULL in case of an
> error. This does not allow to return correct error codes from LoadImage().
> 
> Let efi_load_pe() return a status code and fill in the entry point in the
> corresponding field of the image object.
> 
> Signed-off-by: Heinrich Schuchardt 

This change makes a lot of sense, yes :). I have no idea what I was
thinking when I put up that weird API.

Reviewed-by: Alexander Graf 


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

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:58 PM Marek Vasut  wrote:
>
> On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> >>> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:
> 
>  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >
> > There are two motivations for this:
> > a) reduce code size to eventually support secure boot (where SPL has to
> >authenticate the next stage by loading/checking U-Boot from a FIT
> >image)
> > b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >(on warm-restart), all bytes to check need to be in one piece. With
> >OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >be a good solution.
> 
>  I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
>  than having some ad-hoc plat data again if we can avoid that.
> >>>
> >>> So you're against the whole OF_PLATDATA thing or how should I understand
> >>> that?
> >>
> >> If we can avoid it, I'd prefer to do so.
> >>
> >>> It's not really ad-hoc, it's the DT converted to C structs. It's just in 
> >>> another
> >>> format, but it's still (sort of) decoupled SW from HW.
> >>>
> >>> As written above, I have two goals I want to achieve with this. Right 
> >>> now, I
> >>> cannot enable verified boot in SPL because the available OCRAM cannot
> >>> hold all the code. And it seemed to me OF_PLATDATA could help me there.
> >>
> >> Well this might be a long shot, but I discussed this lack of OCRAM
> >> during 35C3 and there was a suggestion to lock L2 cache lines above ROM
> >> (so there's some backing store) and use that as extra SRAM. Would that
> >> help you ?
> >
> > I would have joined that discussion if my Family would have let me go 
> > during the
> > holidays :-))
> >
> > This is an interesing idea, but actually it's a lack of code/rodata
> > size. The Intel
> > docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB at
> > max. I have not checked the code size increase I would get when enabling 
> > trusted
> > boot (SPL loading U-Boot from FIT and verifying it with a public key),
> > but I'm currently
> > at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
> > booting from SPI.
> > When booting from MMC, the code is about ~4 KiB smaller but BSS grows to 
> > ~600
> > Bytes.
>
> I wonder if there are some huge chunks of code which could be optimized?
>
> > Of course the stack and initial malloc area do need some bytes too, but I 
> > think
> > summed up, bss, stack and malloc should probably fit into 4 KiB, so I
> > currently have
> > about 15 KiB to add FIT loading and public key verification/hashing. I
> > don't think that's
> > enough just from the code size.
> >
> > And on socfpga, I think all added code would use the heap, which is
> > changed to SDRAM
> > very early, so it's not the RAM that is tight.
>
> Can you check readelf and see how the function size looks ? Maybe
> there's something which is just too big ?

I'm looking at the map file all the time ;-) The only thing that looks
too big is
SDRAM initialization, which is about 16 KiB overall, I think. The rest
just seems
to be smaller parts. But the binary blob u32 arrays created by Quartus don't
help, either: rodata is about 9 KiB.

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

Re: [U-Boot] [PATCH 1/5] efi_loader: LoadImage: always allocate new pages

[Alexander Graf]

On 28.12.18 12:41, Heinrich Schuchardt wrote:
> If we want to properly unload images in Exit() the memory should always be
> allocated in the same way. As we allocate memory when reading from file we
> should do the same when the original image is in memory.
> 
> Further patches will be needed:
> - use LoadImage() in bootefi and bootmgr
> - implement correct unloading of images in Exit()
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  |  2 +-
>  lib/efi_loader/efi_bootmgr.c  |  2 +-
>  lib/efi_loader/efi_boottime.c | 56 ---
>  3 files changed, 40 insertions(+), 20 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 53f08161ab..a4c869b623 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -387,7 +387,7 @@ efi_status_t efi_setup_loaded_image(struct 
> efi_device_path *device_path,
>   struct efi_loaded_image_obj **handle_ptr,
>   struct efi_loaded_image **info_ptr);
>  efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
> -   void **buffer);
> +   void **buffer, efi_uintn_t *size);
>  /* Print information about all loaded images */
>  void efi_print_image_infos(void *pc);
>  
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a095df3f54..196116b547 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -150,7 +150,7 @@ static void *try_load_entry(uint16_t n, struct 
> efi_device_path **device_path,
>   debug("%s: trying to load \"%ls\" from %pD\n",
> __func__, lo.label, lo.file_path);
>  
> - ret = efi_load_image_from_path(lo.file_path, );
> + ret = efi_load_image_from_path(lo.file_path, , );
>  
>   if (ret != EFI_SUCCESS)
>   goto error;
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index f592e4083f..ba76f7ff50 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1566,17 +1566,19 @@ failure:
>  
>  /**
>   * efi_load_image_from_path() - load an image using a file path
> - * @file_path: the path of the image to load
> - * @buffer:buffer containing the loaded image
> + * @file_path:   the path of the image to load
> + * @buffer:  buffer containing the loaded image
> + * @size:size of the loaded image
>   *
>   * Return: status code
>   */
>  efi_status_t efi_load_image_from_path(struct efi_device_path *file_path,
> -   void **buffer)
> +   void **buffer, efi_uintn_t *size)
>  {
>   struct efi_file_info *info = NULL;
>   struct efi_file_handle *f;
>   static efi_status_t ret;
> + u64 addr;
>   efi_uintn_t bs;
>  
>   f = efi_file_from_path(file_path);
> @@ -1594,22 +1596,21 @@ efi_status_t efi_load_image_from_path(struct 
> efi_device_path *file_path,
>   if (ret != EFI_SUCCESS)
>   goto error;
>  
> - ret = efi_allocate_pool(EFI_LOADER_DATA, info->file_size, buffer);
> - if (ret)
> + ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
> +  EFI_RUNTIME_SERVICES_CODE,
> +  efi_size_in_pages(), );

Doesn't efi_size_in_pages() want an argument?

Also, why is this RTS code?

> + if (ret != EFI_SUCCESS) {
> + ret = EFI_OUT_OF_RESOURCES;
>   goto error;
> + }
>  
> + *buffer = (void *)(uintptr_t)addr;
>   bs = info->file_size;
>   EFI_CALL(ret = f->read(f, , *buffer));
>  
>  error:
> - free(info);

Why don't you have to free info anymore? It's a local variable, no?

>   EFI_CALL(f->close(f));
>  
> - if (ret != EFI_SUCCESS) {
> - efi_free_pool(*buffer);

Where do we ever free the pages allocated above?

> - *buffer = NULL;
> - }
> -
>   return ret;
>  }
>  
> @@ -1636,6 +1637,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
> boot_policy,
> efi_uintn_t source_size,
> efi_handle_t *image_handle)
>  {
> + struct efi_device_path *dp, *fp;
>   struct efi_loaded_image *info = NULL;
>   struct efi_loaded_image_obj **image_obj =
>   (struct efi_loaded_image_obj **)image_handle;
> @@ -1655,9 +1657,10 @@ static efi_status_t EFIAPI efi_load_image(bool 
> boot_policy,
>   }
>  
>   if (!source_buffer) {
> - struct efi_device_path *dp, *fp;
> -
> - ret = efi_load_image_from_path(file_path, _buffer);
> + ret = efi_load_image_from_path(file_path, _buffer,
> +_size);
> + if (ret == EFI_OUT_OF_RESOURCES)
> + goto error;

How is error different from failure? And why 

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Marek Vasut]

On 1/8/19 1:38 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:

 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
>
> There are two motivations for this:
> a) reduce code size to eventually support secure boot (where SPL has to
>authenticate the next stage by loading/checking U-Boot from a FIT
>image)
> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
>(on warm-restart), all bytes to check need to be in one piece. With
>OF_SEPARATE, this is not the case (.bss is between .rodata and the
>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
>be a good solution.

 I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
 than having some ad-hoc plat data again if we can avoid that.
>>>
>>> So you're against the whole OF_PLATDATA thing or how should I understand
>>> that?
>>
>> If we can avoid it, I'd prefer to do so.
>>
>>> It's not really ad-hoc, it's the DT converted to C structs. It's just in 
>>> another
>>> format, but it's still (sort of) decoupled SW from HW.
>>>
>>> As written above, I have two goals I want to achieve with this. Right now, I
>>> cannot enable verified boot in SPL because the available OCRAM cannot
>>> hold all the code. And it seemed to me OF_PLATDATA could help me there.
>>
>> Well this might be a long shot, but I discussed this lack of OCRAM
>> during 35C3 and there was a suggestion to lock L2 cache lines above ROM
>> (so there's some backing store) and use that as extra SRAM. Would that
>> help you ?
> 
> I would have joined that discussion if my Family would have let me go during 
> the
> holidays :-))
> 
> This is an interesing idea, but actually it's a lack of code/rodata
> size. The Intel
> docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB at
> max. I have not checked the code size increase I would get when enabling 
> trusted
> boot (SPL loading U-Boot from FIT and verifying it with a public key),
> but I'm currently
> at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
> booting from SPI.
> When booting from MMC, the code is about ~4 KiB smaller but BSS grows to ~600
> Bytes.

I wonder if there are some huge chunks of code which could be optimized?

> Of course the stack and initial malloc area do need some bytes too, but I 
> think
> summed up, bss, stack and malloc should probably fit into 4 KiB, so I
> currently have
> about 15 KiB to add FIT loading and public key verification/hashing. I
> don't think that's
> enough just from the code size.
> 
> And on socfpga, I think all added code would use the heap, which is
> changed to SDRAM
> very early, so it's not the RAM that is tight.

Can you check readelf and see how the function size looks ? Maybe
there's something which is just too big ?

-- 
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 debug uart work on socfpga_gen5

[Marek Vasut]

On 1/8/19 1:42 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:08 PM Marek Vasut  wrote:
>>
>> On 1/8/19 1:06 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:

 On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
 On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
>> On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
 On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> When debug UART is enabled on socfpga_gen5, the debug uart driver
> hangs
> in an endless loop because 'socfpga_bridges_reset' calls printf
> before
> the debug UART is initialized.
>
> After the generic fix for this in the UART driver did not work
> due to
> portability issues, let's just drop this printf statement when
> called
> from SPL with debug UART enabled.
>
> Signed-off-by: Simon Goldschmidt 

 Can we have an un-portable fix which at least works on SoCFPGA ? :)
>>>
>>> This one worked on socfpga but broke rockchip:
>>>
>>> https://patchwork.ozlabs.org/patch/992553/
>>>
>>> However, the message below wasn't shown either with that patch
>>> applied.
>>> The code just runs too early to enable the UART.
>>>
>>> Do you want to keep the message (although I failed to see in which
>>> situation it can be printed) or do you just dislike the #ifdef 
>>> thing?
>>
>> I'd like to keep the error message if possible. Is it possible ?
>
> I have *never* seen this message yet. I have failed to produce a
> situation where it is shown.

 I believe that.

> This function ('socfpga_bridges_reset') is called 5 times throughout 
> the
> code, but only *one* single time with 'reset=0' as argument (only with
> 0, the code in question is executed). And this is in SPL before
> initializing the console and even before the debug UART can be
> initialized.
>
> As I could see, the printf *is* executed on every boot (I saw the code
> hanging when enabling debug UART). However, when not booting from 
> FPGA,
> it is just normal that the FPGA is not ready when running SPL. Why do
> you want an error message here anyway?

 I was under the impression this is an error message, but it might not 
 be
 so ? Maybe the wording is incorrect ?
>>>
>>> Now that I re-read it, "aborting" is incorrect, yes.
>>>
>>> So how should we proceed? This is an error message that can never be
>>> shown (like the code is now) but breaks debug UART.
>>>
>>> I'd say we can drop it altogether. It might only be interesint if (in
>>> the future) that code would get called from somewhere else (i.e. later,
>>> after console initialization).
>>>
>>> Re-reading spl_gen5.c, there are some 'debug' calls before the debug
>>> uart is initialized which probably would need to be removed as well, but
>>> that's a different story...
>>
>> How come those don't hang the system then ?
>
> I just haven't enabled debug output in spl_gen5.c, yet. I guess they 
> would hang
> the system when enabling them.
>
> While it would be easy to remove these debug statements, to be 
> future-proof
> it would of course make sense to make the debug UART robust against this.
>
> But given the problems with Rockchip ns16550, we would need a dedicated
> debug UART for socfpga to solve this. And that would probably mean code
> duplication.

 What is the problem with Rockchip ? I don't want various SoCs blocking
 others.
>>>
>>> I had sent a patch that does not wait for the TX fifo to hold more bytes if 
>>> the
>>> baudrate prescaler is 0 (according to both the socfgpa and the rockchip 
>>> docs,
>>> the UART is disabled if the prescaler is 0).
>>>
>>> However, it seems that the prescaler was read back as 0 on a rockchip board
>>> which caused chars to be missing from the console output.
>>>
>>> See this mail:
>>> https://lists.denx.de/pipermail/u-boot/2018-December/350355.html
>>>
>>> I checked with Henri and did not find a solution so I reverted the patch:
>>> https://patchwork.ozlabs.org/patch/1007211/
>>>
>>> Keeping this patch but only for selected platforms would be my favourite, 
>>> but it
>>> would at least mean we need yet another debug UART selection, plus some 
>>> changes
>>> to make the "prescaler == 0" 

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 1:46 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
>>
>> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
>>> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:

 On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset controller ?
>
> Here again, socfpga seems to be another bad example. Taking
> peripherals out of reset
> is cluttered throughout the mach-socfpga code at least in SPL. By now
> I know socfpga is
> lacking support for clock and reset management via devicetree. And
> this is bad, I know,
> but can we keep this a seperate issue from OF_PLATDATA?
>
> That being said, drivers/reset/reset-uclass.c fails to compile with
> OF_PLATDATA, so I
> guess this has not been used with OF_PLATDATA before. And given that I
> don't seem
> to need it for socfpga either, I don't think this would be the right
> series to fix that.

 Don't you need it to unreset at least the DWMMC or CQSPI ?
>>>
>>> Reading the code, it seems like that's taken care of through another hack in
>>> spl_boot_device() ;-)
>>
>> Sigh.
>>
 Anyway, I'd much prefer to start cleaning up the horrorshow that
 arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
 Would that be possible ?
>>>
>>> I would be best, yes. I don't know when I will find the time to do that, 
>>> though.
>>> I don't know how much effort that would be, either. Is there maybe a patch
>>> where A10 got converted from "as bad as gen5" to its current state? That
>>> would help me to see if I can do it...
>>
>> A10 got switched to reset framework recently (in last 6 months or so),
>> the reset driver is the same for Gen5 and A10 too, so it should be easy
>> to recycle.
> 
> Hmm, ok, let me check that... it would indeed be nice to port this to gen5.
> 
> Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
> to continue on this? I mean, I thought I heard people here saying "use
> OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not 
> too
> keen on using it, either, but it does seem to give me some code space back...

OF_PLATDATA is for platforms with really small SRAM, some 30k or below.
This platform has a massive 60k of SRAM for SPL, so if we're running out
of space, we're doing something wrong.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:22 PM Marek Vasut  wrote:
>
> On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> >>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> 
>  On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> > In order to build a smaller SPL, let's imply SPL_DM_RESET and
> > SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
> > via defconfig.
> >
> > This also seems to be required to use OF_PLATDATA, as the reset drivers
> > don't seem to work with it.
> 
>  How do you un-reset IP blocks if you disable the reset controller ?
> >>>
> >>> Here again, socfpga seems to be another bad example. Taking
> >>> peripherals out of reset
> >>> is cluttered throughout the mach-socfpga code at least in SPL. By now
> >>> I know socfpga is
> >>> lacking support for clock and reset management via devicetree. And
> >>> this is bad, I know,
> >>> but can we keep this a seperate issue from OF_PLATDATA?
> >>>
> >>> That being said, drivers/reset/reset-uclass.c fails to compile with
> >>> OF_PLATDATA, so I
> >>> guess this has not been used with OF_PLATDATA before. And given that I
> >>> don't seem
> >>> to need it for socfpga either, I don't think this would be the right
> >>> series to fix that.
> >>
> >> Don't you need it to unreset at least the DWMMC or CQSPI ?
> >
> > Reading the code, it seems like that's taken care of through another hack in
> > spl_boot_device() ;-)
>
> Sigh.
>
> >> Anyway, I'd much prefer to start cleaning up the horrorshow that
> >> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
> >> Would that be possible ?
> >
> > I would be best, yes. I don't know when I will find the time to do that, 
> > though.
> > I don't know how much effort that would be, either. Is there maybe a patch
> > where A10 got converted from "as bad as gen5" to its current state? That
> > would help me to see if I can do it...
>
> A10 got switched to reset framework recently (in last 6 months or so),
> the reset driver is the same for Gen5 and A10 too, so it should be easy
> to recycle.

Hmm, ok, let me check that... it would indeed be nice to port this to gen5.

Since you seem kidn of opposed to OF_PLATDATA, does it make any sense
to continue on this? I mean, I thought I heard people here saying "use
OF_PLATDATA" if you're running out of space in SPL. After using it, I'm not too
keen on using it, either, but it does seem to give me some code space back...

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

[U-Boot] [PATCH] configs: Enable CONFIG_BLK in a few TI boards

[Faiz Abbas]

With DM conversion completed, enable CONFIG_BLK for a
few pending TI boards.

Signed-off-by: Faiz Abbas 
---
 configs/am335x_boneblack_vboot_defconfig  | 1 -
 configs/am335x_evm_defconfig  | 1 -
 configs/am335x_hs_evm_defconfig   | 1 -
 configs/am335x_hs_evm_uart_defconfig  | 1 -
 configs/am43xx_evm_defconfig  | 1 -
 configs/am43xx_evm_qspiboot_defconfig | 1 -
 configs/am43xx_evm_rtconly_defconfig  | 1 -
 configs/am43xx_evm_usbhost_boot_defconfig | 1 -
 configs/am43xx_hs_evm_defconfig   | 1 -
 configs/am57xx_evm_defconfig  | 1 -
 configs/am57xx_hs_evm_defconfig   | 1 -
 configs/k2g_evm_defconfig | 1 -
 configs/k2g_hs_evm_defconfig  | 1 -
 13 files changed, 13 deletions(-)

diff --git a/configs/am335x_boneblack_vboot_defconfig 
b/configs/am335x_boneblack_vboot_defconfig
index c62e8322fb..093a9b1c8e 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -29,7 +29,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-# CONFIG_BLK is not set
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 0931c1e97f..a0951b05ee 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -26,7 +26,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-# CONFIG_BLK is not set
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_NAND=y
diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 1a7c5cfb17..4de09f8bab 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -32,7 +32,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-# CONFIG_BLK is not set
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_NAND=y
diff --git a/configs/am335x_hs_evm_uart_defconfig 
b/configs/am335x_hs_evm_uart_defconfig
index 147da80f0d..3613c7023d 100644
--- a/configs/am335x_hs_evm_uart_defconfig
+++ b/configs/am335x_hs_evm_uart_defconfig
@@ -34,7 +34,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk 
am335x-bonegreen am335x-icev2"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-# CONFIG_BLK is not set
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_NAND=y
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 481aa4fad9..d58c9c1a25 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -36,7 +36,6 @@ CONFIG_REGMAP=y
 CONFIG_SPL_REGMAP=y
 CONFIG_SYSCON=y
 CONFIG_SPL_SYSCON=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
diff --git a/configs/am43xx_evm_qspiboot_defconfig 
b/configs/am43xx_evm_qspiboot_defconfig
index 0d7bd72157..9dd67f6c44 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -31,7 +31,6 @@ CONFIG_MULTI_DTB_FIT=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
diff --git a/configs/am43xx_evm_rtconly_defconfig 
b/configs/am43xx_evm_rtconly_defconfig
index 7d56db43fd..1448262ba2 100644
--- a/configs/am43xx_evm_rtconly_defconfig
+++ b/configs/am43xx_evm_rtconly_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 5131f190a7..6e90bd02c6 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -40,7 +40,6 @@ CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm 
am437x-idk-evm"
 CONFIG_ENV_IS_IN_FAT=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 5d98e0edee..bff6f0a401 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -38,7 +38,6 @@ CONFIG_DEFAULT_DEVICE_TREE="am437x-gp-evm"
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-# CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
diff --git a/configs/am57xx_evm_defconfig 

Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:08 PM Marek Vasut  wrote:
>
> On 1/8/19 1:06 PM, Simon Goldschmidt wrote:
> > On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:
> >>
> >> On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
> >>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> 
>  On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 21:47 schrieb Marek Vasut:
> >> On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
>  On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 21:19 schrieb Marek Vasut:
> >> On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> >>> When debug UART is enabled on socfpga_gen5, the debug uart driver
> >>> hangs
> >>> in an endless loop because 'socfpga_bridges_reset' calls printf
> >>> before
> >>> the debug UART is initialized.
> >>>
> >>> After the generic fix for this in the UART driver did not work
> >>> due to
> >>> portability issues, let's just drop this printf statement when
> >>> called
> >>> from SPL with debug UART enabled.
> >>>
> >>> Signed-off-by: Simon Goldschmidt 
> >>
> >> Can we have an un-portable fix which at least works on SoCFPGA ? :)
> >
> > This one worked on socfpga but broke rockchip:
> >
> > https://patchwork.ozlabs.org/patch/992553/
> >
> > However, the message below wasn't shown either with that patch
> > applied.
> > The code just runs too early to enable the UART.
> >
> > Do you want to keep the message (although I failed to see in which
> > situation it can be printed) or do you just dislike the #ifdef 
> > thing?
> 
>  I'd like to keep the error message if possible. Is it possible ?
> >>>
> >>> I have *never* seen this message yet. I have failed to produce a
> >>> situation where it is shown.
> >>
> >> I believe that.
> >>
> >>> This function ('socfpga_bridges_reset') is called 5 times throughout 
> >>> the
> >>> code, but only *one* single time with 'reset=0' as argument (only with
> >>> 0, the code in question is executed). And this is in SPL before
> >>> initializing the console and even before the debug UART can be
> >>> initialized.
> >>>
> >>> As I could see, the printf *is* executed on every boot (I saw the code
> >>> hanging when enabling debug UART). However, when not booting from 
> >>> FPGA,
> >>> it is just normal that the FPGA is not ready when running SPL. Why do
> >>> you want an error message here anyway?
> >>
> >> I was under the impression this is an error message, but it might not 
> >> be
> >> so ? Maybe the wording is incorrect ?
> >
> > Now that I re-read it, "aborting" is incorrect, yes.
> >
> > So how should we proceed? This is an error message that can never be
> > shown (like the code is now) but breaks debug UART.
> >
> > I'd say we can drop it altogether. It might only be interesint if (in
> > the future) that code would get called from somewhere else (i.e. later,
> > after console initialization).
> >
> > Re-reading spl_gen5.c, there are some 'debug' calls before the debug
> > uart is initialized which probably would need to be removed as well, but
> > that's a different story...
> 
>  How come those don't hang the system then ?
> >>>
> >>> I just haven't enabled debug output in spl_gen5.c, yet. I guess they 
> >>> would hang
> >>> the system when enabling them.
> >>>
> >>> While it would be easy to remove these debug statements, to be 
> >>> future-proof
> >>> it would of course make sense to make the debug UART robust against this.
> >>>
> >>> But given the problems with Rockchip ns16550, we would need a dedicated
> >>> debug UART for socfpga to solve this. And that would probably mean code
> >>> duplication.
> >>
> >> What is the problem with Rockchip ? I don't want various SoCs blocking
> >> others.
> >
> > I had sent a patch that does not wait for the TX fifo to hold more bytes if 
> > the
> > baudrate prescaler is 0 (according to both the socfgpa and the rockchip 
> > docs,
> > the UART is disabled if the prescaler is 0).
> >
> > However, it seems that the prescaler was read back as 0 on a rockchip board
> > which caused chars to be missing from the console output.
> >
> > See this mail:
> > https://lists.denx.de/pipermail/u-boot/2018-December/350355.html
> >
> > I checked with Henri and did not find a solution so I reverted the patch:
> > https://patchwork.ozlabs.org/patch/1007211/
> >
> > Keeping this patch but only for selected platforms would be my favourite, 
> > but it
> > would at least mean we need yet another debug UART selection, plus some 
> > changes
> > to make the "prescaler == 0" detection specific to this new debug UART.
> > Would 

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:06 PM Marek Vasut  wrote:
>
> On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
> >>>
> >>> There are two motivations for this:
> >>> a) reduce code size to eventually support secure boot (where SPL has to
> >>>authenticate the next stage by loading/checking U-Boot from a FIT
> >>>image)
> >>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
> >>>(on warm-restart), all bytes to check need to be in one piece. With
> >>>OF_SEPARATE, this is not the case (.bss is between .rodata and the
> >>>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
> >>>be a good solution.
> >>
> >> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
> >> than having some ad-hoc plat data again if we can avoid that.
> >
> > So you're against the whole OF_PLATDATA thing or how should I understand
> > that?
>
> If we can avoid it, I'd prefer to do so.
>
> > It's not really ad-hoc, it's the DT converted to C structs. It's just in 
> > another
> > format, but it's still (sort of) decoupled SW from HW.
> >
> > As written above, I have two goals I want to achieve with this. Right now, I
> > cannot enable verified boot in SPL because the available OCRAM cannot
> > hold all the code. And it seemed to me OF_PLATDATA could help me there.
>
> Well this might be a long shot, but I discussed this lack of OCRAM
> during 35C3 and there was a suggestion to lock L2 cache lines above ROM
> (so there's some backing store) and use that as extra SRAM. Would that
> help you ?

I would have joined that discussion if my Family would have let me go during the
holidays :-))

This is an interesing idea, but actually it's a lack of code/rodata
size. The Intel
docs clearly state that the binary SPL loaded from SPI/MMC must be 60 KiB at
max. I have not checked the code size increase I would get when enabling trusted
boot (SPL loading U-Boot from FIT and verifying it with a public key),
but I'm currently
at ~45 KiB for .text, .rodata and DTB and only 40 bytes for BSS. I'm
booting from SPI.
When booting from MMC, the code is about ~4 KiB smaller but BSS grows to ~600
Bytes.

Of course the stack and initial malloc area do need some bytes too, but I think
summed up, bss, stack and malloc should probably fit into 4 KiB, so I
currently have
about 15 KiB to add FIT loading and public key verification/hashing. I
don't think that's
enough just from the code size.

And on socfpga, I think all added code would use the heap, which is
changed to SDRAM
very early, so it's not the RAM that is tight.


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

Re: [U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA

[Marek Vasut]

On 1/8/19 1:14 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:32 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:

 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> 'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is 
> enabled
> since it uses functions accessing the devicetree.
>
> Since this function is not used in SPL anyway, change the compile guard
> to reflect this and fix compiling SPL with OF_PLATDATA.

 Doesn't this break ethernet in SPL ? I think it does. The real fix is to
 move this PHY mode configuration into the driver.
>>>
>>> Hmm, ethernet in SPL. Haven't thought of that :-)
>>>
>>> While it could be easy to move the DTS part of  PHY mode configuration into
>>> the driver, moving the reset portion of that code into the driver would be 
>>> ugly
>>> unless using proper reset management?
>>
>> Well, it's still better than having it live in arch/arm/ , which was at
>> that point the best option, but right now it's no longer. And I think
>> Joyce ran into similar topic with some other Altera IP.
> 
> Hmm, ok, I could search for that.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
>
>  arch/arm/mach-socfpga/misc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index 78fbe28724..30f74d9940 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -120,7 +120,7 @@ int arch_cpu_init(void)
>   return 0;
>  }
>
> -#ifdef CONFIG_ETH_DESIGNWARE
> +#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
>>>
>>> Would it work for you to change this into:
>>>
>>> #if defined CONFIG_ETH_DESIGNWARE && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>
>>> We could still fix the reset code when actually using OF_PLATDATA with
>>> ethernet...
>>
>> Is it too much work to fix it properly ?
> 
> Well, just moving the functions I commented out into the eth driver would mean
> it would at some point call back into arch/arm/mach-socfpga code.
> 
> If that is acceptable, it wouldn't be too much work and I could certainly do 
> it.
> But the question remains whether such a change would "fix it properly". In my
> opinion, it wouldn't. But it would probably still be better than the
> current state
> where some code in arch/arm parses ETH DTS nodes...

Right. I think you can just pull that info from the DT node associated
with the DWMAC driver.

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 1:09 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:

 On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
> via defconfig.
>
> This also seems to be required to use OF_PLATDATA, as the reset drivers
> don't seem to work with it.

 How do you un-reset IP blocks if you disable the reset controller ?
>>>
>>> Here again, socfpga seems to be another bad example. Taking
>>> peripherals out of reset
>>> is cluttered throughout the mach-socfpga code at least in SPL. By now
>>> I know socfpga is
>>> lacking support for clock and reset management via devicetree. And
>>> this is bad, I know,
>>> but can we keep this a seperate issue from OF_PLATDATA?
>>>
>>> That being said, drivers/reset/reset-uclass.c fails to compile with
>>> OF_PLATDATA, so I
>>> guess this has not been used with OF_PLATDATA before. And given that I
>>> don't seem
>>> to need it for socfpga either, I don't think this would be the right
>>> series to fix that.
>>
>> Don't you need it to unreset at least the DWMMC or CQSPI ?
> 
> Reading the code, it seems like that's taken care of through another hack in
> spl_boot_device() ;-)

Sigh.

>> Anyway, I'd much prefer to start cleaning up the horrorshow that
>> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
>> Would that be possible ?
> 
> I would be best, yes. I don't know when I will find the time to do that, 
> though.
> I don't know how much effort that would be, either. Is there maybe a patch
> where A10 got converted from "as bad as gen5" to its current state? That
> would help me to see if I can do it...

A10 got switched to reset framework recently (in last 6 months or so),
the reset driver is the same for Gen5 and A10 too, so it should be easy
to recycle.

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

Re: [U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>
> On 1/8/19 7:32 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> 'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is 
> >>> enabled
> >>> since it uses functions accessing the devicetree.
> >>>
> >>> Since this function is not used in SPL anyway, change the compile guard
> >>> to reflect this and fix compiling SPL with OF_PLATDATA.
> >>
> >> Doesn't this break ethernet in SPL ? I think it does. The real fix is to
> >> move this PHY mode configuration into the driver.
> >
> > Hmm, ethernet in SPL. Haven't thought of that :-)
> >
> > While it could be easy to move the DTS part of  PHY mode configuration into
> > the driver, moving the reset portion of that code into the driver would be 
> > ugly
> > unless using proper reset management?
>
> Well, it's still better than having it live in arch/arm/ , which was at
> that point the best option, but right now it's no longer. And I think
> Joyce ran into similar topic with some other Altera IP.

Hmm, ok, I could search for that.

> >>> Signed-off-by: Simon Goldschmidt 
> >>> ---
> >>>
> >>>  arch/arm/mach-socfpga/misc.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> >>> index 78fbe28724..30f74d9940 100644
> >>> --- a/arch/arm/mach-socfpga/misc.c
> >>> +++ b/arch/arm/mach-socfpga/misc.c
> >>> @@ -120,7 +120,7 @@ int arch_cpu_init(void)
> >>>   return 0;
> >>>  }
> >>>
> >>> -#ifdef CONFIG_ETH_DESIGNWARE
> >>> +#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
> >
> > Would it work for you to change this into:
> >
> > #if defined CONFIG_ETH_DESIGNWARE && !CONFIG_IS_ENABLED(OF_PLATDATA)
> >
> > We could still fix the reset code when actually using OF_PLATDATA with
> > ethernet...
>
> Is it too much work to fix it properly ?

Well, just moving the functions I commented out into the eth driver would mean
it would at some point call back into arch/arm/mach-socfpga code.

If that is acceptable, it wouldn't be too much work and I could certainly do it.
But the question remains whether such a change would "fix it properly". In my
opinion, it wouldn't. But it would probably still be better than the
current state
where some code in arch/arm parses ETH DTS nodes...

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 1:05 PM Marek Vasut  wrote:
>
> On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
> >>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
> >>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
> >>> via defconfig.
> >>>
> >>> This also seems to be required to use OF_PLATDATA, as the reset drivers
> >>> don't seem to work with it.
> >>
> >> How do you un-reset IP blocks if you disable the reset controller ?
> >
> > Here again, socfpga seems to be another bad example. Taking
> > peripherals out of reset
> > is cluttered throughout the mach-socfpga code at least in SPL. By now
> > I know socfpga is
> > lacking support for clock and reset management via devicetree. And
> > this is bad, I know,
> > but can we keep this a seperate issue from OF_PLATDATA?
> >
> > That being said, drivers/reset/reset-uclass.c fails to compile with
> > OF_PLATDATA, so I
> > guess this has not been used with OF_PLATDATA before. And given that I
> > don't seem
> > to need it for socfpga either, I don't think this would be the right
> > series to fix that.
>
> Don't you need it to unreset at least the DWMMC or CQSPI ?

Reading the code, it seems like that's taken care of through another hack in
spl_boot_device() ;-)

> Anyway, I'd much prefer to start cleaning up the horrorshow that
> arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
> Would that be possible ?

I would be best, yes. I don't know when I will find the time to do that, though.
I don't know how much effort that would be, either. Is there maybe a patch
where A10 got converted from "as bad as gen5" to its current state? That
would help me to see if I can do it...

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 debug uart work on socfpga_gen5

[Marek Vasut]

On 1/8/19 1:06 PM, Simon Goldschmidt wrote:
> On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:
>>
>> On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
>>> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:

 On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
>> On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
 On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
>> On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
>>> When debug UART is enabled on socfpga_gen5, the debug uart driver
>>> hangs
>>> in an endless loop because 'socfpga_bridges_reset' calls printf
>>> before
>>> the debug UART is initialized.
>>>
>>> After the generic fix for this in the UART driver did not work
>>> due to
>>> portability issues, let's just drop this printf statement when
>>> called
>>> from SPL with debug UART enabled.
>>>
>>> Signed-off-by: Simon Goldschmidt 
>>
>> Can we have an un-portable fix which at least works on SoCFPGA ? :)
>
> This one worked on socfpga but broke rockchip:
>
> https://patchwork.ozlabs.org/patch/992553/
>
> However, the message below wasn't shown either with that patch
> applied.
> The code just runs too early to enable the UART.
>
> Do you want to keep the message (although I failed to see in which
> situation it can be printed) or do you just dislike the #ifdef thing?

 I'd like to keep the error message if possible. Is it possible ?
>>>
>>> I have *never* seen this message yet. I have failed to produce a
>>> situation where it is shown.
>>
>> I believe that.
>>
>>> This function ('socfpga_bridges_reset') is called 5 times throughout the
>>> code, but only *one* single time with 'reset=0' as argument (only with
>>> 0, the code in question is executed). And this is in SPL before
>>> initializing the console and even before the debug UART can be
>>> initialized.
>>>
>>> As I could see, the printf *is* executed on every boot (I saw the code
>>> hanging when enabling debug UART). However, when not booting from FPGA,
>>> it is just normal that the FPGA is not ready when running SPL. Why do
>>> you want an error message here anyway?
>>
>> I was under the impression this is an error message, but it might not be
>> so ? Maybe the wording is incorrect ?
>
> Now that I re-read it, "aborting" is incorrect, yes.
>
> So how should we proceed? This is an error message that can never be
> shown (like the code is now) but breaks debug UART.
>
> I'd say we can drop it altogether. It might only be interesint if (in
> the future) that code would get called from somewhere else (i.e. later,
> after console initialization).
>
> Re-reading spl_gen5.c, there are some 'debug' calls before the debug
> uart is initialized which probably would need to be removed as well, but
> that's a different story...

 How come those don't hang the system then ?
>>>
>>> I just haven't enabled debug output in spl_gen5.c, yet. I guess they would 
>>> hang
>>> the system when enabling them.
>>>
>>> While it would be easy to remove these debug statements, to be future-proof
>>> it would of course make sense to make the debug UART robust against this.
>>>
>>> But given the problems with Rockchip ns16550, we would need a dedicated
>>> debug UART for socfpga to solve this. And that would probably mean code
>>> duplication.
>>
>> What is the problem with Rockchip ? I don't want various SoCs blocking
>> others.
> 
> I had sent a patch that does not wait for the TX fifo to hold more bytes if 
> the
> baudrate prescaler is 0 (according to both the socfgpa and the rockchip docs,
> the UART is disabled if the prescaler is 0).
> 
> However, it seems that the prescaler was read back as 0 on a rockchip board
> which caused chars to be missing from the console output.
> 
> See this mail:
> https://lists.denx.de/pipermail/u-boot/2018-December/350355.html
> 
> I checked with Henri and did not find a solution so I reverted the patch:
> https://patchwork.ozlabs.org/patch/1007211/
> 
> Keeping this patch but only for selected platforms would be my favourite, but 
> it
> would at least mean we need yet another debug UART selection, plus some 
> changes
> to make the "prescaler == 0" detection specific to this new debug UART.
> Would this be better acceptable?

Doesn't the DT compatible tell you the UART type ? It does, so you can
match on that and apply the workaround accordingly . Or you can cache
the prescaler.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH v1 0/4] arm: socfgpa: support of-platdata

[Marek Vasut]

On 1/8/19 7:56 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:59 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> This is an initial attempt to support OF_PLATDATA for socfpga gen5.
>>>
>>> There are two motivations for this:
>>> a) reduce code size to eventually support secure boot (where SPL has to
>>>authenticate the next stage by loading/checking U-Boot from a FIT
>>>image)
>>> b) to support the cyclone 5 boot ROM's CRC check on the SPL in SRAM
>>>(on warm-restart), all bytes to check need to be in one piece. With
>>>OF_SEPARATE, this is not the case (.bss is between .rodata and the
>>>DTB). Since OF_EMBEDDED has been discouraged, OF_PLATDATA seems to
>>>be a good solution.
>>
>> I'd much prefer parsing the DT (and thus, decoupling the SW from HW)
>> than having some ad-hoc plat data again if we can avoid that.
> 
> So you're against the whole OF_PLATDATA thing or how should I understand
> that?

If we can avoid it, I'd prefer to do so.

> It's not really ad-hoc, it's the DT converted to C structs. It's just in 
> another
> format, but it's still (sort of) decoupled SW from HW.
> 
> As written above, I have two goals I want to achieve with this. Right now, I
> cannot enable verified boot in SPL because the available OCRAM cannot
> hold all the code. And it seemed to me OF_PLATDATA could help me there.

Well this might be a long shot, but I discussed this lack of OCRAM
during 35C3 and there was a suggestion to lock L2 cache lines above ROM
(so there's some backing store) and use that as extra SRAM. Would that
help you ?

-- 
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 debug uart work on socfpga_gen5

[Simon Goldschmidt]

On Tue, Jan 8, 2019 at 12:20 PM Marek Vasut  wrote:
>
> On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
> > On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
> >>
> >> On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
>  On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> > Am 07.01.2019 um 21:25 schrieb Marek Vasut:
> >> On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
> >>> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
>  On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> > When debug UART is enabled on socfpga_gen5, the debug uart driver
> > hangs
> > in an endless loop because 'socfpga_bridges_reset' calls printf
> > before
> > the debug UART is initialized.
> >
> > After the generic fix for this in the UART driver did not work
> > due to
> > portability issues, let's just drop this printf statement when
> > called
> > from SPL with debug UART enabled.
> >
> > Signed-off-by: Simon Goldschmidt 
> 
>  Can we have an un-portable fix which at least works on SoCFPGA ? :)
> >>>
> >>> This one worked on socfpga but broke rockchip:
> >>>
> >>> https://patchwork.ozlabs.org/patch/992553/
> >>>
> >>> However, the message below wasn't shown either with that patch
> >>> applied.
> >>> The code just runs too early to enable the UART.
> >>>
> >>> Do you want to keep the message (although I failed to see in which
> >>> situation it can be printed) or do you just dislike the #ifdef thing?
> >>
> >> I'd like to keep the error message if possible. Is it possible ?
> >
> > I have *never* seen this message yet. I have failed to produce a
> > situation where it is shown.
> 
>  I believe that.
> 
> > This function ('socfpga_bridges_reset') is called 5 times throughout the
> > code, but only *one* single time with 'reset=0' as argument (only with
> > 0, the code in question is executed). And this is in SPL before
> > initializing the console and even before the debug UART can be
> > initialized.
> >
> > As I could see, the printf *is* executed on every boot (I saw the code
> > hanging when enabling debug UART). However, when not booting from FPGA,
> > it is just normal that the FPGA is not ready when running SPL. Why do
> > you want an error message here anyway?
> 
>  I was under the impression this is an error message, but it might not be
>  so ? Maybe the wording is incorrect ?
> >>>
> >>> Now that I re-read it, "aborting" is incorrect, yes.
> >>>
> >>> So how should we proceed? This is an error message that can never be
> >>> shown (like the code is now) but breaks debug UART.
> >>>
> >>> I'd say we can drop it altogether. It might only be interesint if (in
> >>> the future) that code would get called from somewhere else (i.e. later,
> >>> after console initialization).
> >>>
> >>> Re-reading spl_gen5.c, there are some 'debug' calls before the debug
> >>> uart is initialized which probably would need to be removed as well, but
> >>> that's a different story...
> >>
> >> How come those don't hang the system then ?
> >
> > I just haven't enabled debug output in spl_gen5.c, yet. I guess they would 
> > hang
> > the system when enabling them.
> >
> > While it would be easy to remove these debug statements, to be future-proof
> > it would of course make sense to make the debug UART robust against this.
> >
> > But given the problems with Rockchip ns16550, we would need a dedicated
> > debug UART for socfpga to solve this. And that would probably mean code
> > duplication.
>
> What is the problem with Rockchip ? I don't want various SoCs blocking
> others.

I had sent a patch that does not wait for the TX fifo to hold more bytes if the
baudrate prescaler is 0 (according to both the socfgpa and the rockchip docs,
the UART is disabled if the prescaler is 0).

However, it seems that the prescaler was read back as 0 on a rockchip board
which caused chars to be missing from the console output.

See this mail:
https://lists.denx.de/pipermail/u-boot/2018-December/350355.html

I checked with Henri and did not find a solution so I reverted the patch:
https://patchwork.ozlabs.org/patch/1007211/

Keeping this patch but only for selected platforms would be my favourite, but it
would at least mean we need yet another debug UART selection, plus some changes
to make the "prescaler == 0" detection specific to this new debug UART.
Would this be better acceptable?

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

Re: [U-Boot] [PATCH v1 2/4] arm: socfpga: fix compiling with OF_PLATDATA

[Marek Vasut]

On 1/8/19 7:32 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> 'socfpga_eth_reset_common' must not be compiled when OF_PLATDATA is enabled
>>> since it uses functions accessing the devicetree.
>>>
>>> Since this function is not used in SPL anyway, change the compile guard
>>> to reflect this and fix compiling SPL with OF_PLATDATA.
>>
>> Doesn't this break ethernet in SPL ? I think it does. The real fix is to
>> move this PHY mode configuration into the driver.
> 
> Hmm, ethernet in SPL. Haven't thought of that :-)
> 
> While it could be easy to move the DTS part of  PHY mode configuration into
> the driver, moving the reset portion of that code into the driver would be 
> ugly
> unless using proper reset management?

Well, it's still better than having it live in arch/arm/ , which was at
that point the best option, but right now it's no longer. And I think
Joyce ran into similar topic with some other Altera IP.

>>> Signed-off-by: Simon Goldschmidt 
>>> ---
>>>
>>>  arch/arm/mach-socfpga/misc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>>> index 78fbe28724..30f74d9940 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -120,7 +120,7 @@ int arch_cpu_init(void)
>>>   return 0;
>>>  }
>>>
>>> -#ifdef CONFIG_ETH_DESIGNWARE
>>> +#if defined CONFIG_ETH_DESIGNWARE && !defined CONFIG_SPL_BUILD
> 
> Would it work for you to change this into:
> 
> #if defined CONFIG_ETH_DESIGNWARE && !CONFIG_IS_ENABLED(OF_PLATDATA)
> 
> We could still fix the reset code when actually using OF_PLATDATA with
> ethernet...

Is it too much work to fix it properly ?

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

Re: [U-Boot] [PATCH v1 1/4] arm: socfpga: imply SPL config instead of select

[Marek Vasut]

On 1/8/19 7:24 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:14 PM, Simon Goldschmidt wrote:
>>> In order to build a smaller SPL, let's imply SPL_DM_RESET and
>>> SPL_WATCHDOG_SUPPORT instead of selecting them, so they can be disabled
>>> via defconfig.
>>>
>>> This also seems to be required to use OF_PLATDATA, as the reset drivers
>>> don't seem to work with it.
>>
>> How do you un-reset IP blocks if you disable the reset controller ?
> 
> Here again, socfpga seems to be another bad example. Taking
> peripherals out of reset
> is cluttered throughout the mach-socfpga code at least in SPL. By now
> I know socfpga is
> lacking support for clock and reset management via devicetree. And
> this is bad, I know,
> but can we keep this a seperate issue from OF_PLATDATA?
> 
> That being said, drivers/reset/reset-uclass.c fails to compile with
> OF_PLATDATA, so I
> guess this has not been used with OF_PLATDATA before. And given that I
> don't seem
> to need it for socfpga either, I don't think this would be the right
> series to fix that.

Don't you need it to unreset at least the DWMMC or CQSPI ?
Anyway, I'd much prefer to start cleaning up the horrorshow that
arch/arm/mach-socfpga is in terms of clock and reset, at least like A10.
Would that be possible ?

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

Re: [U-Boot] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Laszlo Ersek]

On 01/08/19 10:51, Leif Lindholm wrote:
> MdePkg/MdeModulePkg maintainers - any comments?
> 
> On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote:
>> On 01/07/19 20:22, Leif Lindholm wrote:
>>> On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
>>
 The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit aligned,
 unless specified otherwise. See in "Table 5. Common UEFI Data Types":

   EFI_GUID -- 128-bit buffer containing a unique identifier value.
   Unless otherwise specified, aligned on a 64-bit
   boundary.
>>>
>>> Indeed.
>>>
 Whether edk2 satisfies that, and if so, how (by chance / by general
 build flags), I don't know. The code says,

 ///
 /// 128 bit buffer containing a unique identifier value.
 /// Unless otherwise specified, aligned on a 64 bit boundary.
 ///
 typedef struct {
   UINT32  Data1;
   UINT16  Data2;
   UINT16  Data3;
   UINT8   Data4[8];
 } GUID;

 I think there may have been an expectation in "MdePkg/Include/Base.h"
 that the supported compilers would automatically ensure the specified
 alignment, given the structure definition.
>>>
>>> But that would be expecting things not only not guaranteed by C, but
>>> something there is no semantic information suggesting would be useful
>>> for the compiler to do above. [...]
>>
>> Agreed. I'm not saying the edk2 code is right, just guessing why the
>> code might look like it does. This would not be the first silent
>> assumption, I think.
>>
>> Anyhow, I think it would be better to change the code than the spec.
> 
> Of course it would be better to change the code than the spec.
> 
> But as Ard points out off-thread, doing (as a hack, with gcc)
> 
> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> b/MdePkg/Include/Uefi/UefiBaseType.h
> index 8c9d571eb1..75409f3460 100644
> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
>  ///
>  /// 128-bit buffer containing a unique identifier value.
>  ///
> -typedef GUID  EFI_GUID;
> +typedef GUID  EFI_GUID __attribute__((aligned (8)));
>  ///
>  /// Function return status for EFI API.
>  ///
> 
> breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding
> between ConfigurationTable entries in the system table.

(

More precisely, it adds padding to EFI_CONFIGURATION_TABLE after
"VendorGuid" or after "VendorTable". Padding may not be added at the
beginning of structures, and may not be added anywhere to arrays.

The practical effect is the same, so this is just a side comment about C.

)

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

[U-Boot] [PATCH v2 08/11] configs: colibri_imx7: enable CAAM driver

[Stefan Agner]

From: Stefan Agner 

Access to CAAM in non-secure mode must be enabled by the boot
loader first. The U-Boot CAAM driver enables access to CAAM in
non-secure mode by default. Hence enable the CAAM driver to
allow Linux accessing CAAM directly. This prevents error
messages like the following on Linux boot:
  caam 3090.caam: Entropy delay = 3200
  caam 3090.caam: failed to acquire DECO 0
  caam 3090.caam: failed to instantiate RNG

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 configs/colibri_imx7_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index af976bab12..c6fd7f3f4e 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -2,9 +2,11 @@ CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_MX7=y
 CONFIG_SYS_TEXT_BASE=0x8780
+CONFIG_SECURE_BOOT=y
 CONFIG_TARGET_COLIBRI_IMX7=y
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
+# CONFIG_CMD_DEKBLOB is not set
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_NR_DRAM_BANKS=1
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
@@ -35,6 +37,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
+# CONFIG_CMD_HASH is not set
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
@@ -46,6 +49,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_FSL_CAAM=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 07/11] colibri_imx7: drop legacy usdhc support

[Stefan Agner]

From: Stefan Agner 

Drop legacy pinmux/usdhc board configuration.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
 1 file changed, 97 deletions(-)

diff --git a/board/toradex/colibri_imx7/colibri_imx7.c 
b/board/toradex/colibri_imx7/colibri_imx7.c
index a4c99626b4..392fda92da 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -33,9 +33,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define UART_PAD_CTRL  (PAD_CTL_DSE_3P3V_49OHM | \
PAD_CTL_PUS_PU100KOHM | PAD_CTL_HYS)
 
-#define USDHC_PAD_CTRL (PAD_CTL_DSE_3P3V_32OHM | PAD_CTL_SRE_SLOW | \
-   PAD_CTL_HYS | PAD_CTL_PUE | PAD_CTL_PUS_PU47KOHM)
-
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_PU100KOHM | PAD_CTL_DSE_3P3V_49OHM)
 #define ENET_PAD_CTRL_MII  (PAD_CTL_DSE_3P3V_32OHM)
 
@@ -64,17 +61,6 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_SAI2_TX_SYNC__UART1_DTE_RTS | MUX_PAD_CTRL(UART_PAD_CTRL),
 };
 
-static iomux_v3_cfg_t const usdhc1_pads[] = {
-   MX7D_PAD_SD1_CLK__SD1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD1_CMD__SD1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD1_DATA0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD1_DATA1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD1_DATA2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD1_DATA3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
-   MX7D_PAD_GPIO1_IO00__GPIO1_IO0 | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
 #ifdef CONFIG_USB_EHCI_MX7
 static iomux_v3_cfg_t const usb_cdet_pads[] = {
MX7D_PAD_ENET1_CRS__GPIO7_IO14 | MUX_PAD_CTRL(NO_PAD_CTRL),
@@ -109,24 +95,6 @@ static void setup_gpmi_nand(void)
 }
 #endif
 
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
-   MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA4__SD3_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA5__SD3_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA6__SD3_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_DATA7__SD3_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-   MX7D_PAD_SD3_STROBE__SD3_STROBE  | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-
-   MX7D_PAD_SD3_RESET_B__GPIO6_IO11 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
-};
-#endif
-
 #ifdef CONFIG_VIDEO_MXS
 static iomux_v3_cfg_t const lcd_pads[] = {
MX7D_PAD_LCD_CLK__LCD_CLK | MUX_PAD_CTRL(LCD_PAD_CTRL),
@@ -211,71 +179,6 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
 }
 
-#ifdef CONFIG_FSL_ESDHC
-
-#define USDHC1_CD_GPIO IMX_GPIO_NR(1, 0)
-
-static struct fsl_esdhc_cfg usdhc_cfg[] = {
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-   {USDHC3_BASE_ADDR},
-#endif
-   {USDHC1_BASE_ADDR, 0, 4},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
-   int ret = 0;
-
-   switch (cfg->esdhc_base) {
-   case USDHC1_BASE_ADDR:
-   ret = !gpio_get_value(USDHC1_CD_GPIO);
-   break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-   case USDHC3_BASE_ADDR:
-   ret = 1;
-   break;
-#endif
-   }
-
-   return ret;
-}
-
-int board_mmc_init(bd_t *bis)
-{
-   int i, ret;
-   /* USDHC1 is mmc0, USDHC3 is mmc1 */
-   for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) {
-   switch (i) {
-   case 0:
-   imx_iomux_v3_setup_multiple_pads(
-   usdhc1_pads, ARRAY_SIZE(usdhc1_pads));
-   gpio_request(USDHC1_CD_GPIO, "usdhc1_cd");
-   gpio_direction_input(USDHC1_CD_GPIO);
-   usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
-   break;
-#ifdef CONFIG_TARGET_COLIBRI_IMX7_EMMC
-   case 1:
-   imx_iomux_v3_setup_multiple_pads(usdhc3_emmc_pads,
-   ARRAY_SIZE(usdhc3_emmc_pads));
-   usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
-   break;
-#endif
-   default:
-   printf("Warning: you configured more USDHC controllers"
-   "(%d) than supported by the board\n", i + 1);
-   return -EINVAL;
-   }
-
-   ret = fsl_esdhc_initialize(bis, _cfg[i]);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
-}
-#endif
-
 #ifdef CONFIG_FEC_MXC

[U-Boot] [PATCH v2 06/11] configs: colibri_imx7: use DM_MMC

[Stefan Agner]

From: Stefan Agner 

Now that device tree is in place use DM_MMC for Colibri iMX7
devices.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 configs/colibri_imx7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 0c9467e136..af976bab12 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -49,6 +49,7 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_MTD=y
 CONFIG_NAND=y
@@ -63,7 +64,6 @@ CONFIG_DM_PMIC=y
 CONFIG_PMIC_RN5T567=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="Toradex"
 CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
-- 
2.20.1

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

[U-Boot] [PATCH v2 11/11] configs: add default configuraiton for Colibri iMX7 with eMMC

[Stefan Agner]

From: Stefan Agner 

Add a default configuration for Colibri iMX7D 1GB (with eMMC
NAND flash).

Signed-off-by: Stefan Agner 
---

Changes in v2:
- Add CONFIG_FIT/DFU/CRC32_VERIFY/CMD_GPT/DFU_MMC and FAT_WRITE

 configs/colibri_imx7_emmc_defconfig | 66 +
 1 file changed, 66 insertions(+)
 create mode 100644 configs/colibri_imx7_emmc_defconfig

diff --git a/configs/colibri_imx7_emmc_defconfig 
b/configs/colibri_imx7_emmc_defconfig
new file mode 100644
index 00..5e2a204a88
--- /dev/null
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -0,0 +1,66 @@
+CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
+CONFIG_ARCH_MX7=y
+CONFIG_SYS_TEXT_BASE=0x8780
+CONFIG_SECURE_BOOT=y
+CONFIG_TARGET_COLIBRI_IMX7=y
+CONFIG_TARGET_COLIBRI_IMX7_EMMC=y
+CONFIG_IMX_RDC=y
+CONFIG_IMX_BOOTAUX=y
+# CONFIG_CMD_DEKBLOB is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_FIT=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
+CONFIG_BOOTDELAY=1
+# CONFIG_USE_BOOTCOMMAND is not set
+# CONFIG_CONSOLE_MUX is not set
+CONFIG_SYS_CONSOLE_IS_IN_ENV=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SYS_PROMPT="Colibri iMX7 # "
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+CONFIG_CMD_ASKENV=y
+CONFIG_CRC32_VERIFY=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_CMD_BMP=y
+CONFIG_CMD_CACHE=y
+# CONFIG_CMD_HASH is not set
+# CONFIG_ISO_PARTITION is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-emmc"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_FSL_CAAM=y
+CONFIG_DFU_MMC=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
+CONFIG_FSL_ESDHC=y
+CONFIG_PHYLIB=y
+CONFIG_PHY_MICREL=y
+CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX7=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RN5T567=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Toradex"
+CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
+CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
+CONFIG_CI_UDC=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_VIDEO=y
+CONFIG_FAT_WRITE=y
+CONFIG_OF_LIBFDT_OVERLAY=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 10/11] configs: colibri_imx7: use distro defaults

[Stefan Agner]

From: Stefan Agner 

The defconfig already use most features implied by distro defaults.
Make sure we enable all features required by distro boot by making
use of CONFIG_DISTRO_DEFAULTS.

Signed-off-by: Stefan Agner 
---

Changes in v2:
- New patch

 configs/colibri_imx7_defconfig | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 2e675a0c1d..91577ed36b 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -7,18 +7,17 @@ CONFIG_TARGET_COLIBRI_IMX7=y
 CONFIG_IMX_RDC=y
 CONFIG_IMX_BOOTAUX=y
 # CONFIG_CMD_DEKBLOB is not set
-CONFIG_ENV_VARS_UBOOT_CONFIG=y
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=1
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
 CONFIG_BOOTDELAY=1
+# CONFIG_USE_BOOTCOMMAND is not set
 # CONFIG_CONSOLE_MUX is not set
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Colibri iMX7 # "
 # CONFIG_CMD_BOOTD is not set
-CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_XIMG is not set
 CONFIG_CMD_ASKENV=y
@@ -32,19 +31,15 @@ CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_NAND_TORTURE=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
+# CONFIG_BOOTP_PXE is not set
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 # CONFIG_CMD_HASH is not set
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)"
 CONFIG_CMD_UBI=y
+# CONFIG_ISO_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand"
 CONFIG_ENV_IS_IN_NAND=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 09/11] configs: colibri_imx7: use DFU for NAND instead of MMC

[Stefan Agner]

From: Stefan Agner 

The colibri_imx7_defconfig is for Colibri iMX7 raw NAND devices.
Hence DFU for NAND is more useful then for MMC devices.

Signed-off-by: Stefan Agner 
---

Changes in v2:
- New patch

 configs/colibri_imx7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index c6fd7f3f4e..2e675a0c1d 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -50,7 +50,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_FSL_CAAM=y
-CONFIG_DFU_MMC=y
+CONFIG_DFU_NAND=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 02/11] arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices

[Stefan Agner]

From: Stefan Agner 

In preparation of adding CONFIG_DM_MMC support use separate device
trees for raw NAND and eMMC devices.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2:
- Remove imx7-colibri.dtb from Makefile

 arch/arm/dts/Makefile |  3 +-
 arch/arm/dts/imx7-colibri-emmc.dts| 16 +++
 arch/arm/dts/imx7-colibri-rawnand.dts | 46 +++
 .../{imx7-colibri.dts => imx7-colibri.dtsi}   | 39 +---
 board/toradex/colibri_imx7/MAINTAINERS|  3 ++
 configs/colibri_imx7_defconfig|  2 +-
 6 files changed, 68 insertions(+), 41 deletions(-)
 create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
 create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
 rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (65%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dda4e59491..768965a9fe 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -458,8 +458,7 @@ dtb-$(CONFIG_MX6UL) += \
 
 dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
 
-dtb-$(CONFIG_MX7) += imx7-colibri.dtb \
-   imx7d-sdb.dtb \
+dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
imx7d-sdb-qspi.dtb
 
 dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts 
b/arch/arm/dts/imx7-colibri-emmc.dts
new file mode 100644
index 00..295ca05916
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+   model = "Toradex Colibri iMX7D 1GB (eMMC)";
+   compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
+
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/imx7-colibri-rawnand.dts 
b/arch/arm/dts/imx7-colibri-rawnand.dts
new file mode 100644
index 00..4eb86fb011
--- /dev/null
+++ b/arch/arm/dts/imx7-colibri-rawnand.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * Copyright 2019 Toradex AG
+ */
+
+/dts-v1/;
+#include "imx7-colibri.dtsi"
+
+/ {
+   model = "Toradex Colibri iMX7S/D";
+   compatible = "toradex,imx7-colibri", "fsl,imx7";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpmi_nand>;
+   fsl,use-minimum-ecc;
+   nand-on-flash-bbt;
+   nand-ecc-mode = "hw";
+   status = "okay";
+};
+
+ {
+   pinctrl_gpmi_nand: gpmi-nand-grp {
+   fsl,pins = <
+   MX7D_PAD_SD3_CLK__NAND_CLE  0x71
+   MX7D_PAD_SD3_CMD__NAND_ALE  0x71
+   MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B   0x71
+   MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
+   MX7D_PAD_SD3_STROBE__NAND_RE_B  0x71
+   MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
+   MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
+   MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
+   MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
+   MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
+   MX7D_PAD_SD3_DATA4__NAND_DATA04 0x71
+   MX7D_PAD_SD3_DATA5__NAND_DATA05 0x71
+   MX7D_PAD_SD3_DATA6__NAND_DATA06 0x71
+   MX7D_PAD_SD3_DATA7__NAND_DATA07 0x71
+   >;
+   };
+};
diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dtsi
similarity index 65%
rename from arch/arm/dts/imx7-colibri.dts
rename to arch/arm/dts/imx7-colibri.dtsi
index dca501be25..47295117aa 100644
--- a/arch/arm/dts/imx7-colibri.dts
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -1,30 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0+ OR X11
 /*
- * Copyright 2016 Toradex AG
+ * Copyright 2016-2019 Toradex AG
  */
 
 /dts-v1/;
 #include 
 #include "imx7d.dtsi"
 
-/ {
-   model = "Toradex Colibri iMX7S/D";
-   compatible = "toradex,imx7-colibri", "fsl,imx7";
-
-   chosen {
-   stdout-path = 
-   };
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpmi_nand>;
-   fsl,use-minimum-ecc;
-   nand-on-flash-bbt;
-   nand-ecc-mode = "hw";
-   status = "okay";
-};
-
  {
pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c1>;
@@ -57,25 +39,6 @@
 };
 
  {
-   pinctrl_gpmi_nand: gpmi-nand-grp {
-   fsl,pins = <
-   MX7D_PAD_SD3_CLK__NAND_CLE  0x71
-   MX7D_PAD_SD3_CMD__NAND_ALE  0x71
-   MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B   0x71
-   MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
-   MX7D_PAD_SD3_STROBE__NAND_RE_B  0x71
-   MX7D_PAD_SD3_RESET_B__NAND_WE_B 

[U-Boot] [PATCH v2 04/11] configs: colibri_imx7: use separate device tree

[Stefan Agner]

From: Stefan Agner 

Use OF_SEPARATE as suggested by the build system.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 configs/colibri_imx7_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 3aaf1a417d..0c9467e136 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -43,7 +43,6 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:512k(mx7-bcb),1536k(u-boot1)ro,1536k(u-boot2)ro,512k(u-boot-env),-(ubi)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
-CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="imx7-colibri-rawnand"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 05/11] arm: dts: imx7: colibri: add usdhci peripherals to device tree

[Stefan Agner]

From: Stefan Agner 

Add usdhci peripherals to device tree. This allows to use DM_MMC
for Colibri iMX7 devices.

Signed-off-by: Stefan Agner 
---

Changes in v2:
- Remove unnecessary properties

 arch/arm/dts/imx7-colibri-emmc.dts | 31 ++
 arch/arm/dts/imx7-colibri.dtsi | 26 +
 2 files changed, 57 insertions(+)

diff --git a/arch/arm/dts/imx7-colibri-emmc.dts 
b/arch/arm/dts/imx7-colibri-emmc.dts
index 295ca05916..efd600091d 100644
--- a/arch/arm/dts/imx7-colibri-emmc.dts
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -10,7 +10,38 @@
model = "Toradex Colibri iMX7D 1GB (eMMC)";
compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
 
+   aliases {
+   mmc0 = 
+   mmc1 = 
+   };
+
chosen {
stdout-path = 
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usdhc3>;
+   bus-width = <8>;
+   non-removable;
+   status = "okay";
+};
+
+ {
+   pinctrl_usdhc3: usdhc3grp {
+   fsl,pins = <
+   MX7D_PAD_SD3_CMD__SD3_CMD   0x59
+   MX7D_PAD_SD3_CLK__SD3_CLK   0x19
+   MX7D_PAD_SD3_DATA0__SD3_DATA0   0x59
+   MX7D_PAD_SD3_DATA1__SD3_DATA1   0x59
+   MX7D_PAD_SD3_DATA2__SD3_DATA2   0x59
+   MX7D_PAD_SD3_DATA3__SD3_DATA3   0x59
+   MX7D_PAD_SD3_DATA4__SD3_DATA4   0x59
+   MX7D_PAD_SD3_DATA5__SD3_DATA5   0x59
+   MX7D_PAD_SD3_DATA6__SD3_DATA6   0x59
+   MX7D_PAD_SD3_DATA7__SD3_DATA7   0x59
+   MX7D_PAD_SD3_STROBE__SD3_STROBE 0x19
+   >;
+   };
+};
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index 47295117aa..a85702f519 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -38,6 +38,15 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usdhc1 _cd_usdhc1>;
+   no-1-8-v;
+   cd-gpios = < 0 GPIO_ACTIVE_LOW>;
+   disable-wp;
+   status = "okay";
+};
+
  {
pinctrl_i2c4: i2c4-grp {
fsl,pins = <
@@ -68,6 +77,17 @@
MX7D_PAD_SD2_DATA0__GPIO5_IO14  0x14 /* DTR */
>;
};
+
+   pinctrl_usdhc1: usdhc1-grp {
+   fsl,pins = <
+   MX7D_PAD_SD1_CMD__SD1_CMD   0x59
+   MX7D_PAD_SD1_CLK__SD1_CLK   0x19
+   MX7D_PAD_SD1_DATA0__SD1_DATA0   0x59
+   MX7D_PAD_SD1_DATA1__SD1_DATA1   0x59
+   MX7D_PAD_SD1_DATA2__SD1_DATA2   0x59
+   MX7D_PAD_SD1_DATA3__SD1_DATA3   0x59
+   >;
+   };
 };
 
 _lpsr {
@@ -84,4 +104,10 @@
MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x407f
>;
};
+
+   pinctrl_cd_usdhc1: usdhc1-cd-grp {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO00__GPIO1_IO0 0x59 /* CD */
+   >;
+   };
 };
-- 
2.20.1

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

[U-Boot] [PATCH v2 03/11] configs: colibri_imx7: enable DM for raw NAND devices

[Stefan Agner]

From: Stefan Agner 

Use DM and device trees for raw NAND devices by default. This
fixes -74 NAND read errors since it makes sure the ECC settings
are the same as used in Linux and our downstream U-Boot.

Signed-off-by: Stefan Agner 
---

Changes in v2: None

 configs/colibri_imx7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 7441102ed4..3aaf1a417d 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -25,6 +25,7 @@ CONFIG_CMD_DFU=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
 CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_NAND_TORTURE=y
 CONFIG_CMD_USB=y
@@ -50,7 +51,9 @@ CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND=y
+CONFIG_NAND_MXS_DT=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 01/11] colibri_imx7: fix boot commands

[Stefan Agner]

From: Stefan Agner 

Fix mixed up boot commands between raw NAND and eMMC variant. Also
make sure that the boot_file is defined for the eMMC boot command.

Fixes: a62c60610f51 ("colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module 
support")
Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 
---

Changes in v2: None

 include/configs/colibri_imx7.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index c31cf2888a..5a4b9801cb 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -110,13 +110,13 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #if defined(CONFIG_TARGET_COLIBRI_IMX7_NAND)
-#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
"setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run distro_bootcmd;"
 #define MODULE_EXTRA_ENV_SETTINGS \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
UBI_BOOTCMD
 #elif defined(CONFIG_TARGET_COLIBRI_IMX7_EMMC)
-#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
+#define CONFIG_BOOTCOMMAND "run emmcboot ; echo ; echo emmcboot failed ; " \
"setenv fdtfile ${soc}-colibri-emmc-${fdt_board}.dtb && run 
distro_bootcmd;"
 #define MODULE_EXTRA_ENV_SETTINGS \
"variant=-emmc\0" \
@@ -143,6 +143,7 @@
NFS_BOOTCMD \
SD_BOOTCMD \
MODULE_EXTRA_ENV_SETTINGS \
+   "boot_file=zImage\0" \
"console=ttymxc0\0" \
"defargs=\0" \
"fdt_board=eval-v3\0" \
-- 
2.20.1

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

[U-Boot] [PATCH v2 00/11] arm: Colibri iMX7 fixes and DM_MMC conversion

[Stefan Agner]

From: Stefan Agner 

This patchset fixes some small issues with Colibri iMX7 and
converts the board to use DM_MMC. It also adds the so far
missing configuration for the eMMC variant.

This patchset gets rid of all but one deprecation warning.
The remaining warning is due to CONFIG_USB still being used.
Fixing this is not entirly trivial due to missing GPIO host/
peripheral switch capabilities and will be tackled later.

--
Stefan

Changes in v2:
- Remove imx7-colibri.dtb from Makefile
- Remove unnecessary properties
- New patch
- New patch
- Add CONFIG_FIT/DFU/CRC32_VERIFY/CMD_GPT/DFU_MMC and FAT_WRITE

Stefan Agner (11):
  colibri_imx7: fix boot commands
  arm: dts: imx7: colibri: split dt for raw NAND and eMMC devices
  configs: colibri_imx7: enable DM for raw NAND devices
  configs: colibri_imx7: use separate device tree
  arm: dts: imx7: colibri: add usdhci peripherals to device tree
  configs: colibri_imx7: use DM_MMC
  colibri_imx7: drop legacy usdhc support
  configs: colibri_imx7: enable CAAM driver
  configs: colibri_imx7: use DFU for NAND instead of MMC
  configs: colibri_imx7: use distro defaults
  configs: add default configuraiton for Colibri iMX7 with eMMC

 arch/arm/dts/Makefile |  3 +-
 arch/arm/dts/imx7-colibri-emmc.dts| 47 +
 arch/arm/dts/imx7-colibri-rawnand.dts | 46 +
 .../{imx7-colibri.dts => imx7-colibri.dtsi}   | 65 ++---
 board/toradex/colibri_imx7/MAINTAINERS|  3 +
 board/toradex/colibri_imx7/colibri_imx7.c | 97 ---
 configs/colibri_imx7_defconfig| 27 +++---
 configs/colibri_imx7_emmc_defconfig   | 66 +
 include/configs/colibri_imx7.h|  5 +-
 9 files changed, 207 insertions(+), 152 deletions(-)
 create mode 100644 arch/arm/dts/imx7-colibri-emmc.dts
 create mode 100644 arch/arm/dts/imx7-colibri-rawnand.dts
 rename arch/arm/dts/{imx7-colibri.dts => imx7-colibri.dtsi} (68%)
 create mode 100644 configs/colibri_imx7_emmc_defconfig

-- 
2.20.1

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

Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support

[Andre Przywara]

On Tue, 8 Jan 2019 16:27:14 +0530
Jagan Teki  wrote:

Hi,

> On Mon, Jan 7, 2019 at 6:35 AM André Przywara
>  wrote:
> >
> > On 31/12/2018 16:59, Jagan Teki wrote:  
> > > Clock control unit comprises of parent clocks, gates,
> > > multiplexers, dividers, multipliers, pre/post dividers and flags
> > > etc.
> > >
> > > So, the U-Boot implementation of ccu has divided into gates and
> > > tree. gates are generic clock configuration of enable/disable bit
> > > management which can be handle via ccu_clock_gate.  
> >
> > So if I understand this correctly, you implement the gate
> > functionality separately from the complex clock code, even if they
> > are the same clock from the DT point of view? So if one wants to
> > enable the MMC0 clock, which is a mux/divider clock, one needs to
> > specify an extra entry in the gate array to describe the enable bit
> > in this special clock register? Sounds a bit surprising, but is
> > probably a neat trick to keep things simple. There should be a
> > comment in the code to this regard then.  
> 
> Exactly. Idea is to keep the macro's as simple as possible.
> 
> Adding gates clocks separately make easy and reasonable way to
> enable/disable clock operations. We even operate with single macro
> with all clock attributes along with gate(either another member or
> common structure like Linux does), but that seems not simple as per as
> my experince since there are many IP's like USB's just need
> enable/disable.
> 
> >  
> > > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm,
> > > nkmp, pre/post div, flags etc. which were managed via
> > > ccu_clock_tree.  
> >
> > For a start, can we use more descriptive names than those very
> > specific MP/NK names? DIV_MUX and PLL sound more descriptive to me.
> > I understand that Linux uses those terms, but it would be great if
> > uninitiated people have a chance to understand this as well.
> >  
> > > This patch add support for MP, NK, MISC, FIXED clock types as
> > > part of ccu clock tree with get_rate functionality this
> > > eventually used by uart driver. and rest of the infrastructure
> > > will try to add while CLK is being used on respective peripherals.
> > >
> > > Note that few of the tree type clock would require to enable
> > > gates on their specific clock, in that case we need to add the
> > > gate details via ccu_clock_gate, example: MP with gate so the
> > > gate offset, bit value should add as part of ccu_clock_gate.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > >  arch/arm/include/asm/arch-sunxi/ccu.h | 192
> > > +- drivers/clk/sunxi/clk_a64.c
> > > |  40 ++ drivers/clk/sunxi/clk_sunxi.c | 182
> > >  3 files changed, 413 insertions(+), 1
> > > deletion(-)
> > >
> > > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h
> > > b/arch/arm/include/asm/arch-sunxi/ccu.h index
> > > 3fdc26978d..61b8c36b3b 100644 ---
> > > a/arch/arm/include/asm/arch-sunxi/ccu.h +++
> > > b/arch/arm/include/asm/arch-sunxi/ccu.h @@ -7,15 +7,204 @@
> > >  #ifndef _ASM_ARCH_CCU_H
> > >  #define _ASM_ARCH_CCU_H
> > >
> > > +#define OSC_32K_ULL  32000ULL  
> >
> > 32768
> >
> > And why ULL? The whole Allwinner clock system works with 32-bit
> > values, so just U would be totally sufficient. This avoid blowing
> > this up to 64 bit unnecessarily, which sounds painful for those
> > poor ARMv7 parts. 
> > > +#define OSC_24M_ULL  2400ULL
> > > +
> > > +/**
> > > + * enum ccu_clk_type - ccu clock types
> > > + *
> > > + * @CCU_CLK_TYPE_MISC:   misc clock type  
> >
> > What is MISC, exactly? Seems like an artefact clock to me, some
> > placeholder you need because gate clocks are handled separately in
> > the gates struct. Should this be called something with SIMPLE
> > instead, or GATE?  
> 
> Unlike MP type in MMC, UART doesn't need any clock attributes like
> dividers, mux, etc, just have attached parent. I don't think UART
> clock is simple one It has parent, that indeed have another parents
> and so...on, ie reason I named as MISC.

Not really, as far as I can see the UART clock is a just a gate clock as
many others, with one parent (APB2).
The fact that APB2 in turn can have multiple parents doesn't affect the
UART clock itself, as you model this via the clock tree.

In fact we could have similar clocks in the tree structure for the
other gate clocks (USB, for instance), it's just that the UART is the
only user so far which actually queries the clock rate.

So MISC is way too generic, I would still prefer CCU_CLK_TYPE_GATE.

> > > + * @CCU_CLK_TYPE_FIXED:  fixed clock type
> > > + * @CCU_CLK_TYPE_MP: mp clock type
> > > + * @CCU_CLK_TYPE_NK: nk clock type  
> >
> > What is the point of those comments, as you are basically repeating
> > the enum name? What about:
> >  * @CCU_CLK_TYPE_PLL:   PLL clock with two multiplier fields
> >  * @CCU_CLK_TYPE_MUX_DIV:   

[U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Jean-Jacques Hiblot]

This series applies on top of u-boot-dfu.

This series renames CONFIG_SPL_USB_GADGET_SUPPORT to CONFIG_SPL_USB_GADGET
for consistency.
It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
sure that the code is not included if it is not needed. Some defconfigs
had to be updated as they relied on the gadget code to be always compiled.

TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900

Jean-Jacques Hiblot (2):
  Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET
  usb: Make compiling gadget support optional

 Makefile | 4 ++--
 arch/arm/mach-imx/mx6/Kconfig| 2 +-
 arch/arm/mach-imx/spl.c  | 2 +-
 common/spl/Kconfig   | 4 ++--
 configs/am335x_boneblack_vboot_defconfig | 2 +-
 configs/am335x_evm_usbspl_defconfig  | 2 +-
 configs/am43xx_evm_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig  | 2 +-
 configs/apalis_imx6_defconfig| 2 +-
 configs/cm_t3517_defconfig   | 1 +
 configs/cm_t35_defconfig | 1 +
 configs/colibri_imx6_defconfig   | 2 +-
 configs/display5_factory_defconfig   | 2 +-
 configs/duovero_defconfig| 1 +
 configs/igep0032_defconfig   | 1 +
 configs/igep00x0_defconfig   | 1 +
 configs/imx6q_logic_defconfig| 2 +-
 configs/mx6memcal_defconfig  | 2 +-
 configs/mx6sabresd_defconfig | 2 +-
 configs/omap3_zoom1_defconfig| 1 +
 configs/omap4_panda_defconfig| 1 +
 configs/omap4_sdp4430_defconfig  | 1 +
 configs/pico-hobbit-imx6ul_defconfig | 2 +-
 configs/pico-hobbit-imx7d_defconfig  | 2 +-
 configs/pico-imx6ul_defconfig| 2 +-
 configs/pico-imx7d_defconfig | 2 +-
 configs/pico-pi-imx6ul_defconfig | 2 +-
 configs/pico-pi-imx7d_defconfig  | 2 +-
 configs/spear300_usbtty_defconfig| 2 ++
 configs/spear300_usbtty_nand_defconfig   | 2 ++
 configs/spear310_usbtty_defconfig| 2 ++
 configs/spear310_usbtty_nand_defconfig   | 2 ++
 configs/spear310_usbtty_pnor_defconfig   | 2 ++
 configs/spear320_usbtty_defconfig| 2 ++
 configs/spear320_usbtty_nand_defconfig   | 2 ++
 configs/spear320_usbtty_pnor_defconfig   | 2 ++
 configs/spear600_usbtty_defconfig| 2 ++
 configs/spear600_usbtty_nand_defconfig   | 2 ++
 drivers/Makefile | 6 +++---
 drivers/usb/gadget/Makefile  | 2 +-
 scripts/Makefile.spl | 2 +-
 41 files changed, 55 insertions(+), 27 deletions(-)

-- 
2.7.4

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

Re: [U-Boot] [PATCH PATCH v1 0/2] Use CONFIG_USB_GADGET and CONFIG_SPL_USB_GADGET to select the USB gadget code

[Marek Vasut]

On 1/8/19 11:40 AM, Jean-Jacques Hiblot wrote:
> 
> This series applies on top of u-boot-dfu.
> 
> This series renames CONFIG_SPL_USB_GADGET_SUPPORT to CONFIG_SPL_USB_GADGET
> for consistency.
> It also uses CONFIG_USB_GADGET to compile-in the gadget code. This make
> sure that the code is not included if it is not needed. Some defconfigs
> had to be updated as they relied on the gadget code to be always compiled.
> 
> TRAVIS: https://travis-ci.org/jjhiblot/u-boot/builds/476452900
> 
> Jean-Jacques Hiblot (2):
>   Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET
>   usb: Make compiling gadget support optional
> 
>  Makefile | 4 ++--
>  arch/arm/mach-imx/mx6/Kconfig| 2 +-
>  arch/arm/mach-imx/spl.c  | 2 +-
>  common/spl/Kconfig   | 4 ++--
>  configs/am335x_boneblack_vboot_defconfig | 2 +-
>  configs/am335x_evm_usbspl_defconfig  | 2 +-
>  configs/am43xx_evm_defconfig | 2 +-
>  configs/am43xx_hs_evm_defconfig  | 2 +-
>  configs/apalis_imx6_defconfig| 2 +-
>  configs/cm_t3517_defconfig   | 1 +
>  configs/cm_t35_defconfig | 1 +
>  configs/colibri_imx6_defconfig   | 2 +-
>  configs/display5_factory_defconfig   | 2 +-
>  configs/duovero_defconfig| 1 +
>  configs/igep0032_defconfig   | 1 +
>  configs/igep00x0_defconfig   | 1 +
>  configs/imx6q_logic_defconfig| 2 +-
>  configs/mx6memcal_defconfig  | 2 +-
>  configs/mx6sabresd_defconfig | 2 +-
>  configs/omap3_zoom1_defconfig| 1 +
>  configs/omap4_panda_defconfig| 1 +
>  configs/omap4_sdp4430_defconfig  | 1 +
>  configs/pico-hobbit-imx6ul_defconfig | 2 +-
>  configs/pico-hobbit-imx7d_defconfig  | 2 +-
>  configs/pico-imx6ul_defconfig| 2 +-
>  configs/pico-imx7d_defconfig | 2 +-
>  configs/pico-pi-imx6ul_defconfig | 2 +-
>  configs/pico-pi-imx7d_defconfig  | 2 +-
>  configs/spear300_usbtty_defconfig| 2 ++
>  configs/spear300_usbtty_nand_defconfig   | 2 ++
>  configs/spear310_usbtty_defconfig| 2 ++
>  configs/spear310_usbtty_nand_defconfig   | 2 ++
>  configs/spear310_usbtty_pnor_defconfig   | 2 ++
>  configs/spear320_usbtty_defconfig| 2 ++
>  configs/spear320_usbtty_nand_defconfig   | 2 ++
>  configs/spear320_usbtty_pnor_defconfig   | 2 ++
>  configs/spear600_usbtty_defconfig| 2 ++
>  configs/spear600_usbtty_nand_defconfig   | 2 ++
>  drivers/Makefile | 6 +++---
>  drivers/usb/gadget/Makefile  | 2 +-
>  scripts/Makefile.spl | 2 +-
>  41 files changed, 55 insertions(+), 27 deletions(-)
> 
I'll let Lukasz handle integrating this. Does it get rid of the patch I
complained about in the PR ? I hope so ..

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

[U-Boot] [PATCH PATCH v1 1/2] Kconfig: rename CONFIG_SPL_USB_GADGET_SUPPORT as CONFIG_SPL_USB_GADGET

[Jean-Jacques Hiblot]

The SPL option for USB gadget should be named after the option for u-boot
(CONFIG_USB_GADGET)

Signed-off-by: Jean-Jacques Hiblot 
---

 arch/arm/mach-imx/mx6/Kconfig| 2 +-
 arch/arm/mach-imx/spl.c  | 2 +-
 common/spl/Kconfig   | 4 ++--
 configs/am335x_boneblack_vboot_defconfig | 2 +-
 configs/am335x_evm_usbspl_defconfig  | 2 +-
 configs/am43xx_evm_defconfig | 2 +-
 configs/am43xx_hs_evm_defconfig  | 2 +-
 configs/apalis_imx6_defconfig| 2 +-
 configs/colibri_imx6_defconfig   | 2 +-
 configs/display5_factory_defconfig   | 2 +-
 configs/imx6q_logic_defconfig| 2 +-
 configs/mx6memcal_defconfig  | 2 +-
 configs/mx6sabresd_defconfig | 2 +-
 configs/pico-hobbit-imx6ul_defconfig | 2 +-
 configs/pico-hobbit-imx7d_defconfig  | 2 +-
 configs/pico-imx6ul_defconfig| 2 +-
 configs/pico-imx7d_defconfig | 2 +-
 configs/pico-pi-imx6ul_defconfig | 2 +-
 configs/pico-pi-imx7d_defconfig  | 2 +-
 drivers/Makefile | 6 +++---
 drivers/usb/gadget/Makefile  | 2 +-
 scripts/Makefile.spl | 2 +-
 22 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index e7cce46..3d56346 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -263,7 +263,7 @@ config TARGET_MX6DL_MAMOJ
select SPL_PINCTRL if SPL
select SPL_SEPARATE_BSS if SPL
select SPL_SERIAL_SUPPORT if SPL
-   select SPL_USB_GADGET_SUPPORT if SPL
+   select SPL_USB_GADGET if SPL
select SPL_USB_HOST_SUPPORT if SPL
select SPL_USB_SDP_SUPPORT if SPL
select SPL_WATCHDOG_SUPPORT if SPL
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 58a9227..397d6d4 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -154,7 +154,7 @@ u32 spl_boot_device(void)
 }
 #endif /* CONFIG_MX7 || CONFIG_IMX8M */
 
-#ifdef CONFIG_SPL_USB_GADGET_SUPPORT
+#ifdef CONFIG_SPL_USB_GADGET
 int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
 {
put_unaligned(CONFIG_USB_GADGET_PRODUCT_NUM + 0xfff, >idProduct);
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 35472f4..37ecbc6 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -776,13 +776,13 @@ config SPL_USB_SUPPORT
  config options. This enables loading from USB using a configured
  device.
 
-config SPL_USB_GADGET_SUPPORT
+config SPL_USB_GADGET
bool "Suppport USB Gadget drivers"
help
  Enable USB Gadget API which allows to enable USB device functions
  in SPL.
 
-if SPL_USB_GADGET_SUPPORT
+if SPL_USB_GADGET
 
 config SPL_USB_ETHER
bool "Support USB Ethernet drivers"
diff --git a/configs/am335x_boneblack_vboot_defconfig 
b/configs/am335x_boneblack_vboot_defconfig
index be04424..eb46ebd 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MUSB_NEW_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM33xx U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
diff --git a/configs/am335x_evm_usbspl_defconfig 
b/configs/am335x_evm_usbspl_defconfig
index ec72538..165b88f 100644
--- a/configs/am335x_evm_usbspl_defconfig
+++ b/configs/am335x_evm_usbspl_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MUSB_NEW_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 # CONFIG_SPL_YMODEM_SUPPORT is not set
 CONFIG_CMD_SPL=y
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 9bbda43..7e134a6 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -16,7 +16,7 @@ CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL"
 CONFIG_SPL_OS_BOOT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 CONFIG_CMD_SPL=y
 CONFIG_CMD_SPL_NAND_OFS=0x0010
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index aaf8d10..0e7a178 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -25,7 +25,7 @@ CONFIG_SPL_NET_SUPPORT=y
 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL"
 CONFIG_SPL_USB_HOST_SUPPORT=y
 CONFIG_SPL_USB_SUPPORT=y
-CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_ETHER=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_NAND=y
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 133fc1a..e02d9bc 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ 

[U-Boot] Please pull from u-boot-i2c

[Heiko Schocher]

Hello Tom,

please pull from u-boot-i2c.git master

The following changes since commit 53240275666acf32cb9811e44eaf2fd571a6cb75:

  Merge tag 'for-v2019.01' of git://git.denx.de/u-boot-video (2019-01-03 
15:34:44 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-i2c.git master

for you to fetch changes up to 37b52c5a91c50c5e56f16d6a52c2835a3839a9e8:


  i2c: i2c-cdns: Use proper input frequency (2019-01-07 11:23:47 +0100)


Marek Vasut (1):
  i2c: xiic: Add Xilinx AXI I2C driver

Tomasz Gorochowik (1):
  i2c: i2c-cdns: Use proper input frequency

 drivers/i2c/Kconfig   |   6 +++
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/i2c-cdns.c|   9 +++-
 drivers/i2c/xilinx_xiic.c | 340 
+

 4 files changed, 355 insertions(+), 1 deletion(-)
 create mode 100644 drivers/i2c/xilinx_xiic.c

pull request content:

- new i2c driver posted from Marek:
  Add Xilinx AXI I2C controller driver based on the Linux i2c-xiic driver

- i2c-cdns: Use proper input frequency
  from Tomasz

travis build looks fine:

https://travis-ci.org/hsdenx/u-boot-i2c/builds/476314217

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

Re: [U-Boot] [PATCH v5 15/26] clk: sunxi: Add ccu clock tree support

[Jagan Teki]

On Mon, Jan 7, 2019 at 6:35 AM André Przywara  wrote:
>
> On 31/12/2018 16:59, Jagan Teki wrote:
> > Clock control unit comprises of parent clocks, gates, multiplexers,
> > dividers, multipliers, pre/post dividers and flags etc.
> >
> > So, the U-Boot implementation of ccu has divided into gates and tree.
> > gates are generic clock configuration of enable/disable bit management
> > which can be handle via ccu_clock_gate.
>
> So if I understand this correctly, you implement the gate functionality
> separately from the complex clock code, even if they are the same clock
> from the DT point of view? So if one wants to enable the MMC0 clock,
> which is a mux/divider clock, one needs to specify an extra entry in the
> gate array to describe the enable bit in this special clock register?
> Sounds a bit surprising, but is probably a neat trick to keep things
> simple. There should be a comment in the code to this regard then.
>
> > Tree clocks are parent clock type, fixed clocks, mp, nk, nkm, nkmp,
> > pre/post div, flags etc. which were managed via ccu_clock_tree.
>
> For a start, can we use more descriptive names than those very specific
> MP/NK names? DIV_MUX and PLL sound more descriptive to me. I understand
> that Linux uses those terms, but it would be great if uninitiated people
> have a chance to understand this as well.
>
> > This patch add support for MP, NK, MISC, FIXED clock types as part of
> > ccu clock tree with get_rate functionality this eventually used by
> > uart driver. and rest of the infrastructure will try to add while CLK
> > is being used on respective peripherals.
> >
> > Note that few of the tree type clock would require to enable gates on
> > their specific clock, in that case we need to add the gate details via
> > ccu_clock_gate, example: MP with gate so the gate offset, bit value
> > should add as part of ccu_clock_gate.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> >  arch/arm/include/asm/arch-sunxi/ccu.h | 192 +-
> >  drivers/clk/sunxi/clk_a64.c   |  40 ++
> >  drivers/clk/sunxi/clk_sunxi.c | 182 
> >  3 files changed, 413 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/arch-sunxi/ccu.h 
> > b/arch/arm/include/asm/arch-sunxi/ccu.h
> > index 3fdc26978d..61b8c36b3b 100644
> > --- a/arch/arm/include/asm/arch-sunxi/ccu.h
> > +++ b/arch/arm/include/asm/arch-sunxi/ccu.h
> > @@ -7,15 +7,204 @@
> >  #ifndef _ASM_ARCH_CCU_H
> >  #define _ASM_ARCH_CCU_H
> >
> > +#define OSC_32K_ULL  32000ULL
>
> 32768
>
> And why ULL? The whole Allwinner clock system works with 32-bit values,
> so just U would be totally sufficient. This avoid blowing this up to 64
> bit unnecessarily, which sounds painful for those poor ARMv7 parts.
>
> > +#define OSC_24M_ULL  2400ULL
> > +
> > +/**
> > + * enum ccu_clk_type - ccu clock types
> > + *
> > + * @CCU_CLK_TYPE_MISC:   misc clock type
>
> What is MISC, exactly? Seems like an artefact clock to me, some
> placeholder you need because gate clocks are handled separately in the
> gates struct. Should this be called something with SIMPLE instead, or GATE?
>
> > + * @CCU_CLK_TYPE_FIXED:  fixed clock type
> > + * @CCU_CLK_TYPE_MP: mp clock type
> > + * @CCU_CLK_TYPE_NK: nk clock type
>
> What is the point of those comments, as you are basically repeating the
> enum name? What about:
>  * @CCU_CLK_TYPE_PLL:   PLL clock with two multiplier fields
>  * @CCU_CLK_TYPE_MUX_DIV:   multiple parents, two divider fields
>
> This gives more speaking names, plus some explanation.

My idea is to give generic name for a given clock type for example MP
clock has different varients like MP clock, MP with DIV, MP with
Postdiv, MP can be MMC etc. same like NK clock type as NK with
postdiv, NK can be PLL.

With this we can expose the base name to outside and keep fill the
require variants during macro initialization. This can avoid to many
names on the same clock based on the different variants.  Yes we can
add proper full detailed comments on the given type.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: socfpga: make debug uart work on socfpga_gen5

[Marek Vasut]

On 1/8/19 7:41 AM, Simon Goldschmidt wrote:
> On Mon, Jan 7, 2019 at 11:58 PM Marek Vasut  wrote:
>>
>> On 1/7/19 10:01 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:47 schrieb Marek Vasut:
 On 1/7/19 9:33 PM, Simon Goldschmidt wrote:
> Am 07.01.2019 um 21:25 schrieb Marek Vasut:
>> On 1/7/19 9:24 PM, Simon Goldschmidt wrote:
>>> Am 07.01.2019 um 21:19 schrieb Marek Vasut:
 On 1/7/19 8:36 PM, Simon Goldschmidt wrote:
> When debug UART is enabled on socfpga_gen5, the debug uart driver
> hangs
> in an endless loop because 'socfpga_bridges_reset' calls printf
> before
> the debug UART is initialized.
>
> After the generic fix for this in the UART driver did not work
> due to
> portability issues, let's just drop this printf statement when
> called
> from SPL with debug UART enabled.
>
> Signed-off-by: Simon Goldschmidt 

 Can we have an un-portable fix which at least works on SoCFPGA ? :)
>>>
>>> This one worked on socfpga but broke rockchip:
>>>
>>> https://patchwork.ozlabs.org/patch/992553/
>>>
>>> However, the message below wasn't shown either with that patch
>>> applied.
>>> The code just runs too early to enable the UART.
>>>
>>> Do you want to keep the message (although I failed to see in which
>>> situation it can be printed) or do you just dislike the #ifdef thing?
>>
>> I'd like to keep the error message if possible. Is it possible ?
>
> I have *never* seen this message yet. I have failed to produce a
> situation where it is shown.

 I believe that.

> This function ('socfpga_bridges_reset') is called 5 times throughout the
> code, but only *one* single time with 'reset=0' as argument (only with
> 0, the code in question is executed). And this is in SPL before
> initializing the console and even before the debug UART can be
> initialized.
>
> As I could see, the printf *is* executed on every boot (I saw the code
> hanging when enabling debug UART). However, when not booting from FPGA,
> it is just normal that the FPGA is not ready when running SPL. Why do
> you want an error message here anyway?

 I was under the impression this is an error message, but it might not be
 so ? Maybe the wording is incorrect ?
>>>
>>> Now that I re-read it, "aborting" is incorrect, yes.
>>>
>>> So how should we proceed? This is an error message that can never be
>>> shown (like the code is now) but breaks debug UART.
>>>
>>> I'd say we can drop it altogether. It might only be interesint if (in
>>> the future) that code would get called from somewhere else (i.e. later,
>>> after console initialization).
>>>
>>> Re-reading spl_gen5.c, there are some 'debug' calls before the debug
>>> uart is initialized which probably would need to be removed as well, but
>>> that's a different story...
>>
>> How come those don't hang the system then ?
> 
> I just haven't enabled debug output in spl_gen5.c, yet. I guess they would 
> hang
> the system when enabling them.
> 
> While it would be easy to remove these debug statements, to be future-proof
> it would of course make sense to make the debug UART robust against this.
> 
> But given the problems with Rockchip ns16550, we would need a dedicated
> debug UART for socfpga to solve this. And that would probably mean code
> duplication.

What is the problem with Rockchip ? I don't want various SoCs blocking
others.

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

Re: [U-Boot] [PATCH v2] usb: xhci-mem: Fix scratchpad array issue

[Marek Vasut]

On 1/8/19 7:34 AM, Bin Meng wrote:
> On Tue, Jan 8, 2019 at 12:00 PM Ye Li  wrote:
>>
>> On 1/7/2019 5:54 PM, Bin Meng wrote:
>>> On Mon, Jan 7, 2019 at 10:45 AM Ye Li  wrote:

 After updating the value of dev_context_ptrs[0], we should flush this
 from cache to memory. Otherwise the xhci controller won't use it.

 Signed-off-by: Ye Li 
 Reviewed-by: Marek Vasut 
 ---
 Changes for v2:
- Change to use sizeof(ctrl->dcbaa->dev_context_ptrs[0])

  drivers/usb/host/xhci-mem.c | 3 +++
  1 file changed, 3 insertions(+)

>>>
>>> Reviewed-by: Bin Meng 
>>>
>>> But you need do the same in xhci_scratchpad_free() too. Please fix it in v3.
>>>
>> The xhci controller has been stopped before calling xhci_scratchpad_free, is 
>> it necessary to
>> add flush in this function? And I don't see other buffers are flushed when 
>> freeing.
>>
> 
> Ah, yes. It's called after HCD reset, so that's not needed.

Shall I pick this for this release then, Bin ?

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