Re: [U-Boot] SPL Platdata howto?

[Simon Goldschmidt]

On Fri, Dec 21, 2018 at 10:20 PM Simon Goldschmidt
 wrote:
>
>
>
> Am Fr., 21. Dez. 2018, 22:16 hat Simon Glass  geschrieben:
>>
>> Hi Simon,
>>
>> On Thu, 20 Dec 2018 at 14:32, Simon Goldschmidt
>>  wrote:
>> >
>> > Am 20.12.2018 um 21:53 schrieb Simon Goldschmidt:
>> > > Am 20.12.2018 um 18:37 schrieb Simon Glass:
>> > >> Hi Simon,
>> > >>
>> > >> On Thu, 20 Dec 2018 at 08:03, Simon Goldschmidt
>> > >>  wrote:
>> > >>>
>> > >>> Am 20.12.2018 um 15:49 schrieb Simon Glass:
>> >  Hi Simon,
>> > 
>> >  On Wed, 19 Dec 2018 at 14:06, Simon Goldschmidt
>> >   wrote:
>> > >
>> > > Hi,
>> > >
>> > > while searching for bytes to save in SPL in order to add FIT 
>> > > signature
>> > > handling, I am currently trying to get socfpga-gen5 to use 
>> > > OF_PLATDATA.
>> > >
>> > > To begin, I stripped down socfpga_socrates_defconfig to absolutely
>> > > nothing but serial drivers in SPL (with some modifications to the
>> > > Kconfig) and enabled DEBUG_UART to see what's going on.
>> > >
>> > > Now while this config runs OK with a dtb (it just won't boot as 
>> > > drivers
>> > > are missing -> "failed to boot from all boot devices"), it does not 
>> > > find
>> > > the serial driver after enabling OF_PLATDATA.
>> > >
>> > > So since serial_rockchip.c already uses OF_PLATDATA and is based on
>> > > ns16550 that my socfpga-gen5 platform is using: what do I have to do
>> > > besides enabling OF_PLATDATA to get this working?
>> > >
>> > > I just seems like uclass_first_device does not find any UCLASS_SERIAL
>> > > deivce when OF_PLATDATA is enabled.
>> > 
>> >  There is the of-plat.txt README.
>> > >>>
>> > >>> Yes, I should have mentioned I already read that and still had those
>> > >>> questions. Kconfig help says README.platdata though. We probably should
>> > >>> update that link.
>> > >>>
>> >  Basically the dtoc tool creates U_BOOT_DEVICE() declarations and links
>> >  them with SPL. These should show up in your image and therefore be
>> >  bound. You can call dm_dump_all() in SPL to see what what devices are
>> >  bound. I presume you are calling spl_init()?
>> > 
>> >  You can look at what dtoc produces. The example serial driver for
>> >  Rockchip is serial_rockchip.c
>> > >>>
>> > >>> I saw that as an example (because I also have an ns16550 compatible on
>> > >>> my board) but couldn't figure out why it is not bound. By debugging
>> > >>> 'dm_scan_platdata', 'lists_bind_drivers' and 'device_bind_by_name', by
>> > >>> now I know the driver names don't match. That is something I did not 
>> > >>> get
>> > >>> just by reading of-plat.txt. I'll work on a patch to clarify that 
>> > >>> document.
>> > >>
>> > >> Yes I'd really appreciate some patches here. It is hard to know what
>> > >> people won't understand and this feature could really do with a more
>> > >> details docs or a walk-through.
>> > >>
>> > >>>
>> > >>> Right now, serial works. I had to add a new platform specific driver
>> > >>> just like serial_rockchip though. For DTS, we can pass multiple
>> > >>> 'compatible' strings, but for platdata, we have to create multiple
>> > >>> drivers. That's a bit strange when porting boards...
>> > >>
>> > >> Yes it is. I'm not sure how to solve that though. Probably dtoc can be
>> > >> made smarter. Ideally you only need one device of each uclass in SPL.
>> > >
>> > > Would it work to use the unchanged 'compatible' string for the '.name'
>> > > of U_BOOT_DEVICE generated by dtoc? Then the binding of such drivers
>> > > could change from comparing names to comparing to compatibles. That
>> > > would make it more DTS-like.
>> > >
>> > > Then, I think we could need some kind of fallback code for properties
>> > > that are optional in the DTS. Maybe we can create defines for each dtd
>> > > struct so that drivers can test the existence of dtd sturct fields using
>> > > #ifdef. [Given the special usage, I guess it's OK to assume that theses
>> > > structs are only used once per DTS so that we don't have to worry about
>> > > how to solve this for multiple occurrences with different optional
>> > > parameters?]
>> > >
>> > > Oh, and then I think dtb_platdata.py should create the dtd instances as
>> > > const. I'll prepare a patch for that.
>> > >
>> > >>
>> > >>>
>> > 
>> > >
>> > > (And when answering this, keep in mind I need to get MMC and QSPI
>> > > drivers working with OF_PLATDATA - I already fixed compiler errors in
>> > > those, nothing more.)
>> > 
>> >  Yes MMC should be OK, but QSPI might be blazing a bit of a trail.
>> >
>> > Hmm, QSPI works as well when hacking the things that the driver wants to
>> > parse from subnode properties. However, I haven't found a way to access
>> > the platform data of the spi-flash from the driver.
>> >
>> > Maybe we need to somehow make subnodes available in the dt-platdata
>> > structs to make that 

Re: [U-Boot] [PATCH v4 00/10] Improvements for the dwc3_generic driver

[Jon Nettleton]

On Fri, Dec 7, 2018 at 8:46 AM Jean-Jacques Hiblot  wrote:
>
>
> On 06/12/2018 21:56, Loic Devulder wrote:
> > Hi,
> >
> > I re-tested this series on Khadas VIM1 and it still fix the USB issue I
> > had with 'usb reset' (I already tested v2 patches).
> >
> > I just have a message and I'm not sure that I had it last time:
> > "Error disabling PHY supply
> > Can't shutdown USB PHY1 for dwc3@c900"
> >
> > But USB stack looks ok, I can plug/unplug USB key  and do the reset, all
> > works as expected.
> >
> > Since my last test lot of changes has been done in Amlogic SoCs, maybe
> > it's because of this?
> >
> > So if you want you can add my tested-by flag.
> > Tested-by: Loic Devulder 
> Thank you for testing
> >
> > On 11/29/18 10:52 AM, Jean-Jacques Hiblot wrote:
> >> This series aims at bringing improvements to the dwc3_generic driver so
> >> that it can be used by most of the platforms using the dwc3 controller.
> >>
> >> I tested this on with DRA7 and AM57x platforms for both Peripheral and Host
> >> operations. The code to enable DM USB host & dev support for those
> >> platforms will be submitted in a separate series.
> >>
> >> Michal Simek has tested this series:
> >> " I have tested it on zcu100 with usb stick, usb to ethernet converter and
> >> also dfu.
> >> Tested-by: Michal Simek "
> >>
> >> Enhancements:
> >> - use separate Kconfig option for DM USB Periphal and DM USB Host. This
> >> allow platforms to keep their non-DM USB peripheral code and use the DM
> >> USB host.
> >> - fixes the bind/probe confusion in dwc3_generic. The probe is done when
> >> the USB device is first needed.
> >> - handles PHYs when in the peripheral mode. The code to handle the PHYs is
> >> shared with the host side
> >> - handles clock and reset
> >> - bind host controller to the more generic driver 'xhci-dwc3'
> >>
> >>
> >> Changes in v4:
> >> - rebased on latest U-Boot
> >> - renamed DM_USB_DEV as DM_USB_GADGET
> >> - Add a new commit to create a new UCLASS for USB gadget drivers
> >>
> >> Changes in v3:
> >> - fixes bug dwc3_setup_phy(): the phy arrays wasn't returned. This was
> >>visible only when the device is removed.
> >> - Stub the DWC3 PHY operations if CONFIG_IS_ENABLED(PHY) is false.
> >>This fixes all build issues but one (evb-rk3328).
> >> - Fix build issue with evb-rk3328 by enabling CONFIG_USB_DWC3. This has
> >>little impact on the footprint and should not break the runtime as the
> >>xhci-rockchip driver has its own probe function.
> >>Nevertheless this was !!! NOT TESTED !!! by lack of hw
> >>
> >> Changes in v2:
> >> - Updated commit log
> >> - Fixed typo in thordown.c
> >> - select DM_USB_DEV by default for zynqmp platforms
> >>
> >> Jean-Jacques Hiblot (10):
> >>usb: gadget: Do not call board_usb_xxx() directly in USB gadget
> >>  drivers
> >>usb: introduce a separate config option for DM USB device
> >>usb: udc: implement DM versions of
> >>  usb_gadget_initialize()/_release()/_handle_interrupt()
> >>dwc3_generic: do not probe the USB device driver when it's bound
> >>dwc3: move phy operation to core.c
> >>dm: usb: create a new UCLASS ID for USB gadget devices
> >>configs: evb-rk3328: Enable CONFIG_USB_DWC3
> >>dwc3-generic: Handle the PHYs, the clocks and the reset lines
> >>dwc3-generic: Add select_dr_mode operation
> >>usb: dwc3: Fix a compilation error with the edison defconfig
> >>
> >>   arch/arm/Kconfig|   2 +
> >>   board/sunxi/board.c |   2 +-
> >>   cmd/fastboot.c  |   4 +-
> >>   cmd/rockusb.c   |   4 +-
> >>   cmd/thordown.c  |   4 +-
> >>   cmd/usb_gadget_sdp.c|   4 +-
> >>   cmd/usb_mass_storage.c  |   4 +-
> >>   common/dfu.c|   6 +-
> >>   configs/evb-rk3328_defconfig|   1 +
> >>   drivers/usb/Kconfig |  14 +++
> >>   drivers/usb/dwc3/Kconfig|   7 +-
> >>   drivers/usb/dwc3/core.c |  89 ++-
> >>   drivers/usb/dwc3/dwc3-generic.c | 208 
> >> 
> >>   drivers/usb/dwc3/ep0.c  |   2 +-
> >>   drivers/usb/gadget/ether.c  |  40 ++-
> >>   drivers/usb/gadget/udc/Makefile |   4 +
> >>   drivers/usb/gadget/udc/udc-core.c   |   3 +-
> >>   drivers/usb/gadget/udc/udc-uclass.c |  58 ++
> >>   drivers/usb/host/xhci-dwc3.c|  95 ++--
> >>   drivers/usb/musb-new/omap2430.c |   2 +-
> >>   drivers/usb/musb-new/sunxi.c|   2 +-
> >>   include/dm/uclass-id.h  |   1 +
> >>   include/dwc3-uboot.h|  19 
> >>   include/linux/usb/gadget.h  |  18 
> >>   24 files changed, 401 insertions(+), 192 deletions(-)
> >>   create mode 100644 drivers/usb/gadget/udc/udc-uclass.c
> >>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> 

[U-Boot] [GIT] Pull request: u-boot-dfu (04.01.2019)

[Lukasz Majewski]

Dear Marek,

The following changes since commit
7436f5e54d35bcad53befec90e2e67288071f74e:

  Merge tag 'for-master-20190103' of git://git.denx.de/u-boot-rockchip
  (2019-01-03 08:39:44 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-dfu.git 

for you to fetch changes up to deb73d0aea6ca09ecb56ea3431d3151427fff4a4:

  dm: usb: gadget: Fix boot breakage on sunxi platforms (2019-01-03
  22:43:02 +0100)


Jean-Jacques Hiblot (3):
  dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports
  ARM: dts: define USB aliases for all omap5 platforms
  dm: usb: gadget: Fix boot breakage on sunxi platforms

 arch/arm/dts/omap5-u-boot.dtsi  | 5 +
 drivers/usb/gadget/udc/Makefile | 3 ++-
 drivers/usb/gadget/udc/udc-uclass.c | 7 +--
 3 files changed, 12 insertions(+), 3 deletions(-)


Travis-Ci: https://travis-ci.org/lmajewski/u-boot-dfu/builds/475053011


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


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

Re: [U-Boot] [PATCH v2 3/7] riscv: use invalidate/flush_*cache_range functions in cache.c

[Rick Chen]

> > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > Sent: Friday, January 04, 2019 8:38 AM
> > To: u-boot@lists.denx.de
> > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin Meng; Greentime Hu
> > Subject: [PATCH v2 3/7] riscv: use invalidate/flush_*cache_range functions 
> > in
> > cache.c
> >
> > The flush_cache() function in lib/cache.c ignores its arguments and flushes 
> > the
> > complete data and instruction caches. Use the
> > invalidate/flush_*cache_range() functions instead to only flush the 
> > requested
> > memory region.
> >
> > This patch does not change the current behavior of U-Boot, since the
> > implementation of the invalidate/flush_*cache_range() functions flush the
> > complete data and instruction caches. It is in preparation for CPUs with the
> > necessary functionality for flushing a selectable memory range.
> >
> > Signed-off-by: Lukas Auer 
> > ---
> >
> > Changes in v2:
> > - New patch "riscv: use invalidate/flush_*cache_range functions in cache.c"
> >
> >  arch/riscv/lib/cache.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c index
> > 78b19da2c5..5437a122a1 100644
> > --- a/arch/riscv/lib/cache.c
> > +++ b/arch/riscv/lib/cache.c
> > @@ -40,8 +40,8 @@ void cache_flush(void)
> >
> >  void flush_cache(unsigned long addr, unsigned long size)  {
> > - invalidate_icache_all();
> > - flush_dcache_all();
> > + invalidate_icache_range(addr, addr + size);
> > + flush_dcache_range(addr, addr + size);
> >  }
> >
> >  __weak void icache_enable(void)
> > --

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

Re: [U-Boot] [PATCH v2 2/7] riscv: move the AX25-specific implementation of flush_dcache_all

[Rick Chen]

> > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > Sent: Friday, January 04, 2019 8:37 AM
> > To: u-boot@lists.denx.de
> > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin Meng; Greentime Hu
> > Subject: [PATCH v2 2/7] riscv: move the AX25-specific implementation of
> > flush_dcache_all
> >
> > The fence instruction is used to enforce device I/O and memory ordering
> > constraints in RISC-V. It can not be relied on to directly affect the data 
> > cache on
> > every CPU.
> > Andes' AX25 does not have a coherence agent. Its fence instruction flushes 
> > the
> > data cache and is used to keep data in the system coherent.
> > The implementation of flush_dcache_all in lib/cache.c is therefore specific 
> > to the
> > AX25. Move it into the AX25-specific cache.c in cpu/ax25/.
> >
> > This also adds a missing new line between flush_dcache_all and
> > flush_dcache_range in lib/cache.c.
> >
> > Signed-off-by: Lukas Auer 
> > ---
> >
> > Changes in v2:
> > - Replace patch "riscv: remove invalid dcache flush implementation" with new
> > patch "riscv: move the AX25-specific implementation of flush_dcache_all"
> >
> >  arch/riscv/cpu/ax25/cache.c | 22 ++
> >  arch/riscv/lib/cache.c  | 10 --
> >  2 files changed, 26 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c index
> > 8d6ae170b8..228fc55f56 100644
> > --- a/arch/riscv/cpu/ax25/cache.c
> > +++ b/arch/riscv/cpu/ax25/cache.c
> > @@ -6,6 +6,28 @@
> >
> >  #include 
> >
> > +void flush_dcache_all(void)
> > +{
> > + /*
> > +  * Andes' AX25 does not have a coherence agent. U-Boot must use data
> > +  * cache flush and invalidate functions to keep data in the system
> > +  * coherent.
> > +  * The implementation of the fence instruction in the AX25 flushes the
> > +  * data cache and is used for this purpose.
> > +  */
> > + asm volatile ("fence" ::: "memory");
> > +}
> > +
> > +void flush_dcache_range(unsigned long start, unsigned long end) {
> > + flush_dcache_all();
> > +}
> > +
> > +void invalidate_dcache_range(unsigned long start, unsigned long end) {
> > + flush_dcache_all();
> > +}
> > +
> >  void icache_enable(void)
> >  {
> >  #ifndef CONFIG_SYS_ICACHE_OFF
> > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c index
> > ae5c60716f..78b19da2c5 100644
> > --- a/arch/riscv/lib/cache.c
> > +++ b/arch/riscv/lib/cache.c
> > @@ -11,13 +11,12 @@ void invalidate_icache_all(void)
> >   asm volatile ("fence.i" ::: "memory");  }
> >
> > -void flush_dcache_all(void)
> > +__weak void flush_dcache_all(void)
> >  {
> > - asm volatile ("fence" :::"memory");
> >  }
> > -void flush_dcache_range(unsigned long start, unsigned long end)
> > +
> > +__weak void flush_dcache_range(unsigned long start, unsigned long end)
> >  {
> > - flush_dcache_all();
> >  }
> >
> >  void invalidate_icache_range(unsigned long start, unsigned long end) @@ 
> > -29,9
> > +28,8 @@ void invalidate_icache_range(unsigned long start, unsigned long 
> > end)
> >   invalidate_icache_all();
> >  }
> >
> > -void invalidate_dcache_range(unsigned long start, unsigned long end)
> > +__weak void invalidate_dcache_range(unsigned long start, unsigned long
> > +end)
> >  {
> > - flush_dcache_all();
> >  }
> >
> >  void cache_flush(void)
> > --

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

Re: [U-Boot] [PATCH 2/6] riscv: remove invalid dcache flush implementation

[Rick Chen]

Hi Lukas

Auer, Lukas  於 2019年1月4日 週五 上午8:40寫道：
>
> Hi Rick,
>
> On Thu, 2019-01-03 at 08:48 +0800, Rick Chen wrote:
> > Hi Lukas
> >
> > Auer, Lukas  於 2019年1月2日 週三 下午8:22寫道：
> > > Hi Rick,
> > >
> > > On Wed, 2019-01-02 at 10:54 +0800, Rick Chen wrote:
> > > > Hi Lukas
> > > >
> > > > > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > > > > > Sent: Monday, December 31, 2018 2:28 AM
> > > > > > To: u-boot@lists.denx.de
> > > > > > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin
> > > > > > Meng;
> > > > > > Greentime Hu
> > > > > > Subject: [PATCH 2/6] riscv: remove invalid dcache flush
> > > > > > implementation
> > > > > >
> > > > > > The fence instruction is used to enforce device I/O and
> > > > > > memory
> > > > > > ordering
> > > > > > constraints in RISC-V. It does not directly affect the data
> > > > > > cache
> > > > > > and particular
> > > > > > cannot be used to flush or invalidate it. RISC-V does not
> > > > > > have
> > > > > > instructions for
> > > > > > explicit cache control. Remove the flush_dcache_all
> > > > > > implementation and its use
> > > > > > in all dcache-specific functions in lib/cache.c.
> > > > > >
> > > >
> > > > The privileged mention that fence is for the purposes of
> > > > ordering,
> > > > but
> > > > does not say
> > > > it can not be used to flush or invalidate.
> > > >
> > > > Andes's ax25 have no coherence agent. So it need fence
> > > > instruction to
> > > > manipulate
> > > > cache flush or invalidate. Or there will be some data
> > > > synchronization
> > > > error
> > > > occurs on ae350 platform.
> > > >
> > >
> > > I was not aware of this. Does the ax25 flush the whole dcache on
> > > any
> > > fence instruction?
> >
> > Yes.
> > It will flush the whole dcache when execute fence.
> >
> > > You are right, we can't remove it in this case. Since it is
> > > specific to
> > > the ax25, should I move it into cpu/ax25/cache.c instead?
> >
> > OK
> > It is good to me.
> > And thanks for your understanding and improvements.
> >
>
> You are welcome! I just submitted version 2 of the patch series.
>

OK
Thanks for your efforts.

B.R
Rick

> Thanks,
> Lukas
>
> > Regards
> > Rick
> >
> > > Thanks,
> > > Lukas
> > >
> > > > Thanks
> > > > Rick
> > > >
> > > >
> > > > > > This also adds a missing new line between flush_dcache_all
> > > > > > and
> > > > > > flush_dcache_range in lib/cache.c.
> > > > > >
> > > > > > Signed-off-by: Lukas Auer 
> > > > > > ---
> > > > > > This patch only removes the implementation itself and its use
> > > > > > in
> > > > > > dcache-specific
> > > > > > functions in lib/cache.c. There are more uses of it in
> > > > > > arch/riscv/, which this patch
> > > > > > does not remove.
> > > > > >
> > > > > >  arch/riscv/lib/cache.c | 4 +---
> > > > > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> > > > > > index
> > > > > > ae5c60716f..203e287612 100644
> > > > > > --- a/arch/riscv/lib/cache.c
> > > > > > +++ b/arch/riscv/lib/cache.c
> > > > > > @@ -13,11 +13,10 @@ void invalidate_icache_all(void)
> > > > > >
> > > > > >  void flush_dcache_all(void)
> > > > > >  {
> > > > > > - asm volatile ("fence" :::"memory");
> > > > > >  }
> > > > > > +
> > > > > >  void flush_dcache_range(unsigned long start, unsigned long
> > > > > > end)  {
> > > > > > - flush_dcache_all();
> > > > > >  }
> > > > > >
> > > > > >  void invalidate_icache_range(unsigned long start, unsigned
> > > > > > long
> > > > > > end) @@ -31,7
> > > > > > +30,6 @@ void invalidate_icache_range(unsigned long start,
> > > > > > unsigned long end)
> > > > > >
> > > > > >  void invalidate_dcache_range(unsigned long start, unsigned
> > > > > > long
> > > > > > end)  {
> > > > > > - flush_dcache_all();
> > > > > >  }
> > > > > >
> > > > > >  void cache_flush(void)
> > > > > > --
> > > > > > 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] LX2160AQDS: Adds SECURE_BOOT defconfig.

[Udit Agarwal]

Configs added to enable secure boot on LX2160AQDS board.

Signed-off-by: Udit Agarwal 
---
 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 90 
 1 file changed, 90 insertions(+)
 create mode 100644 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig

diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
new file mode 100644
index 00..c53a7ac350
--- /dev/null
+++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LX2160AQDS=y
+CONFIG_SYS_TEXT_BASE=0x8200
+CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
+CONFIG_SECURE_BOOT=y
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-qds"
+CONFIG_NR_DRAM_BANKS=3
+CONFIG_DM=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_TFABOOT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 
earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m 
hugepagesz=1024m hugepages=2 pci=pcie_bus_perf"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_EEPROM=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_MP=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM_SERIAL=y
+CONFIG_SERIAL_PROBE_ALL=y
+CONFIG_CONS_INDEX=0
+CONFIG_FSL_CAAM=y
+CONFIG_FSL_ESDHC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MICRON=y
+CONFIG_SPI_FLASH_USE_4K_SECTORS=n
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_NXP_FSPI=y
+CONFIG_FSL_DSPI=y
+CONFIG_FSPI_AHB_EN_4BYTE=y
+CONFIG_SYS_FSPI_AHB_INIT=y
+CONFIG_PHYLIB=y
+CONFIG_NETDEVICES=y
+CONFIG_PHY_GIGE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_PXE=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_EXT2=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LX=y
+CONFIG_E1000=y
+CONFIG_NET=y
+CONFIG_DM_MMC=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_SCSI_AHCI=y
+CONFIG_SCSI=y
+# CONFIG_SYS_FSL_DDR_PHY is not set
+CONFIG_SYS_GEN2_DDR_PHY=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
+CONFIG_PHYLIB_10G=y
+CONFIG_PHY_AQUANTIA=y # X-M11-USXGMII
+CONFIG_PHY_CORTINA=y # X-M7-40G
+CONFIG_PHY_REALTEK=y # RGMII
+CONFIG_PHY_INPHI=y # X-M8-100G
+CONFIG_PHY_VITESSE=y # SGMII PEX RISER
+CONFIG_HUSH_PARSER=y
+CONFIG_DM_SCSI=y
+CONFIG_SATA_CEVA=y
+CONFIG_AHCI=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_RSA_SOFTWARE_EXP=y
-- 
2.17.1

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

[U-Boot] [PATCH 1/1] LX2160AQDS: Adds SECURE_BOOT defconfig.

[Udit Agarwal]

Configs added to enable secure boot on LX2160AQDS board.

Signed-off-by: Udit Agarwal 
---
 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 90 
 1 file changed, 90 insertions(+)
 create mode 100644 configs/lx2160aqds_tfa_SECURE_BOOT_defconfig

diff --git a/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
new file mode 100644
index 00..c53a7ac350
--- /dev/null
+++ b/configs/lx2160aqds_tfa_SECURE_BOOT_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_TARGET_LX2160AQDS=y
+CONFIG_SYS_TEXT_BASE=0x8200
+CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
+CONFIG_SECURE_BOOT=y
+CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-lx2160a-qds"
+CONFIG_NR_DRAM_BANKS=3
+CONFIG_DM=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_TFABOOT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyAMA0,115200 root=/dev/ram0 
earlycon=pl011,mmio32,0x21c ramdisk_size=0x200 default_hugepagesz=1024m 
hugepagesz=1024m hugepages=2 pci=pcie_bus_perf"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_EEPROM=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_CACHE=y
+CONFIG_MP=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_IS_NOWHERE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM_SERIAL=y
+CONFIG_SERIAL_PROBE_ALL=y
+CONFIG_CONS_INDEX=0
+CONFIG_FSL_CAAM=y
+CONFIG_FSL_ESDHC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MICRON=y
+CONFIG_SPI_FLASH_USE_4K_SECTORS=n
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_SST=y
+CONFIG_SPI_FLASH_EON=y
+CONFIG_NXP_FSPI=y
+CONFIG_FSL_DSPI=y
+CONFIG_FSPI_AHB_EN_4BYTE=y
+CONFIG_SYS_FSPI_AHB_INIT=y
+CONFIG_PHYLIB=y
+CONFIG_NETDEVICES=y
+CONFIG_PHY_GIGE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_PXE=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_EXT2=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LX=y
+CONFIG_E1000=y
+CONFIG_NET=y
+CONFIG_DM_MMC=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_STORAGE=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_SCSI_AHCI=y
+CONFIG_SCSI=y
+# CONFIG_SYS_FSL_DDR_PHY is not set
+CONFIG_SYS_GEN2_DDR_PHY=y
+CONFIG_SYS_MALLOC_F=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
+CONFIG_PHYLIB_10G=y
+CONFIG_PHY_AQUANTIA=y # X-M11-USXGMII
+CONFIG_PHY_CORTINA=y # X-M7-40G
+CONFIG_PHY_REALTEK=y # RGMII
+CONFIG_PHY_INPHI=y # X-M8-100G
+CONFIG_PHY_VITESSE=y # SGMII PEX RISER
+CONFIG_HUSH_PARSER=y
+CONFIG_DM_SCSI=y
+CONFIG_SATA_CEVA=y
+CONFIG_AHCI=y
+CONFIG_RSA=y
+CONFIG_SPL_RSA=y
+CONFIG_RSA_SOFTWARE_EXP=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH] exynos: allow SPL to build in thumb mode

[Siarhei Siamashka]

On Wed,  2 Jan 2019 14:31:41 +0100
Guillaume GARDET  wrote:

> Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
> ends-up in the following error:
> 
> Error: Thumb encoding does not support an immediate here -- `msr 
> cpsr_c,#0x13|0xC0'
> 
> Use an intermediate register to be able to use thumb for exynos5 SPL.
> 
> 
> Signed-off-by: Guillaume GARDET 
> 
> Cc: Albert Aribaud 
> Cc: Minkyu Kang 
> Cc: Tom Rini 
> 
> ---
>  arch/arm/mach-exynos/include/mach/system.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-exynos/include/mach/system.h 
> b/arch/arm/mach-exynos/include/mach/system.h
> index 4837781957..81fa9800b4 100644
> --- a/arch/arm/mach-exynos/include/mach/system.h
> +++ b/arch/arm/mach-exynos/include/mach/system.h
> @@ -58,7 +58,8 @@ struct exynos5_sysreg {
>  /* Move 0xd3 value to CPSR register to enable SVC mode */
>  #define svc32_mode_en() __asm__ __volatile__ \
>   ("@ I disable, Mode: 0x13 - SVC\n\t"  \
> -  "msr cpsr_c, #0x13|0xC0\n\t" : : )
> +  "mov r0, #0x13|0xC0\n\t"   \
> +  "msr cpsr_c, r0\n\t" : : )

This line needs "r0" to be also added to the clobber list. If you
don't do this, then you may encounter sporadic r0 corruption
problem depending on the compiler version or optimization settings.

This would be:

"msr cpsr_c, r0\n\t" : : : "r0")

See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html for more
details.

An even better option is to just use something like this and give
the compiler freedom to pick any register:

"msr cpsr_c, %0\n\t" : : "r"(0x13|0xC0))

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

Re: [U-Boot] [PATCH 2/2] lib: fdtdec: fixup fdtdec_get_addr_size

[Keerthy]

On Thursday 03 January 2019 11:44 PM, s...@google.com wrote:
> On 12/21/18 9:24 AM, Keerthy wrote:
>> fix up fdtdec_get_addr_size to use fdtdec_get_addr_size_auto_noparent
>> so that the address cells and size cells are obtained from the
>> parent instead of going by the fixed length.
> 
> This patch makes perfect sense to me. However, I am worried about the
> potential existence of code that assumes the current fixed-size logic;
> in the past when fixing similar issues like this we've often run into
> code that was use "get addr" functions when it should have been using
> "get u32" functions and similar, which then broke when we fixed the
> implementation to do the right thing. I guess we should still apply the
> patch, and fix up any fallout as it appears.

Thanks Simon!

> 
> Applied to u-boot-dm/next, thanks!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Chee, Tien Fong]

On Fri, 2019-01-04 at 03:24 +0100, Marek Vasut wrote:
> On 1/4/19 3:22 AM, Chee, Tien Fong wrote:
> > 
> > On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote:
> > > 
> > > On 1/4/19 1:46 AM, Chee, Tien Fong wrote:
> > > [...]
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 2. What you means with partial loading? partial loading for
> > > > > > periph.rbf
> > > > > > or core.rbf or both rbfs?
> > > > > That you can only load the relevant image from the fitImage,
> > > > > not
> > > > > the
> > > > > entire fitImage, which lets you load the core bitstream in
> > > > > SPL.
> > > > So, you want 2 files periph.rbf.mkimage, and fitImage(contains
> > > > core.rbf) or both periph.rbf and core.rbf in one fitImage?
> > > Does it make sense ?
> > Which one you refer, 1 or 2?
> > 1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf)
> > in
> > FAT partition
> > 2. Both periph.rbf and core.rbf in one fitImage in FAT partition
> One fitImage file containing both .rbf files , stored in whatever
> storage the user needs.
Okay, let me explore feasibility of this kind implementation.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Kconfig: don't pollute Kconfig w/ i.MX8M options for everyone

[Peng Fan]

> -Original Message-
> From: Philipp Tomsich [mailto:philipp.toms...@theobroma-systems.com]
> Sent: 2019年1月4日 1:48
> To: u-boot@lists.denx.de
> Cc: Tom Rini ; Philipp Tomsich
> ; Peng Fan ;
> Masahiro Yamada 
> Subject: [PATCH] Kconfig: don't pollute Kconfig w/ i.MX8M options for
> everyone
> 
> No point in showing the various DRAM options (right in the top-level menu for
> 'Device Drivers') for i.MX8M when configured for a different architecture.
> This wraps an 'if ARCH_IMX8M' around these.
> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
>  drivers/ddr/imx/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/ddr/imx/Kconfig b/drivers/ddr/imx/Kconfig index
> 7e06fb2..09a35e5 100644
> --- a/drivers/ddr/imx/Kconfig
> +++ b/drivers/ddr/imx/Kconfig
> @@ -1 +1,3 @@
> +if ARCH_IMX8M
>  source "drivers/ddr/imx/imx8m/Kconfig"
> +endif

Thanks. Reviewed-by: Peng Fan 

> --
> 2.1.4

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

Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform

[Tom Rini]

On Fri, Jan 04, 2019 at 09:29:47AM +0800, Bin Meng wrote:
> On Thu, Jan 3, 2019 at 9:39 PM Tom Rini  wrote:
> >
> > On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> > > On 26. 12. 18 15:29, Tom Rini wrote:
> > > > On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
> > > >> Hi Michal,
> > > >>
> > > >> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek  
> > > >> wrote:
> > > >>>
> > > >>> On 20. 12. 18 9:09, Bin Meng wrote:
> > >  On Thu, Dec 20, 2018 at 3:55 PM Michal Simek 
> > >   wrote:
> > > >
> > > > Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
> > > >
> > > > Signed-off-by: Michal Simek 
> > > > ---
> > > >
> > > > Patch needs to be applied when this PR is merged.
> > > > https://github.com/swarren/uboot-test-hooks/pull/21
> > > >
> > > > ---
> > > >  .travis.yml | 8 
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/.travis.yml b/.travis.yml
> > > > index 6e4b4ba0a34a..e14e6987e4cf 100644
> > > > --- a/.travis.yml
> > > > +++ b/.travis.yml
> > > > @@ -454,6 +454,14 @@ matrix:
> > > >QEMU_TARGET="arm-softmmu"
> > > >TEST_PY_ID="--id qemu"
> > > >BUILDMAN="^zynq_zc702$"
> > > > +- name: "test/py xilinx_versal_virt"
> > > > +  env:
> > > > +- TEST_PY_BD="xilinx_versal_virt"
> > > > +  TEST_PY_TEST_SPEC="not sleep"
> > > > +  QEMU_TARGET="aarch64-softmmu"
> > > > +  QEMU_VERSION="v3.1.0"
> > > > +  TEST_PY_ID="--id qemu"
> > > > +  BUILDMAN="^xilinx_versal_virt$"
> > > 
> > >  Can we turn on 3.1.0 for all QEMU targets?
> > > >>>
> > > >>> I expected this question.
> > > >>> First of all I wanted to enable an option to be able to wire whatever
> > > >>> version. Even sha1 for not released version.
> > > >>>
> > > >>> I think we can try to test v3.1.0 qemu version for all boards but I 
> > > >>> will
> > > >>> let Tom to decide is we can move or not.
> > > >>>
> > > >>
> > > >> Yes, please try to test that. If everything is good, I see no reason
> > > >> not using it.
> > > >
> > > > Yes, I would also like to move everyone up to v3.1.0 and also having the
> > > > version we use be spelled out will help with future reproducibility.
> > > >
> > >
> > > v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> > > take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
> > > I am happy to keep them on v3.0 and move the rest to v3.1 and let
> > > vexpress guys to figured out what's wrong with v3.1 and configs around.
> > >
> > > What do you think?
> >
> > The error is:
> >  Captured stdout setup 
> > -
> > +u-boot-test-reset vexpress_ca15_tc2 qemu
> > qemu-system-arm: -tftp: invalid option
> >
> > And I guess the problem is that by v3.1.0 -tftp has been removed and we
> > need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
> > the other QEMU-based targets.  Can you update uboot-test-hooks (change
> > .travis.yml to clone your fork of uboot-test-hooks rather than
> > swarren's) to have the modern syntax?  Thanks!
> 
> I think the correct approach is to update uboot-test-hooks and send PR
> to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
> still have U-Boot's .travis.yml point to swarren's git repo, no?

Yes, sorry, to be clear, I was just saying how to debug / confirm the
changes to uboot-test-hooks.

-- 
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 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Marek Vasut]

On 1/4/19 3:22 AM, Chee, Tien Fong wrote:
> On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote:
>> On 1/4/19 1:46 AM, Chee, Tien Fong wrote:
>> [...]
>>
>>>

>
> 2. What you means with partial loading? partial loading for
> periph.rbf
> or core.rbf or both rbfs?
 That you can only load the relevant image from the fitImage, not
 the
 entire fitImage, which lets you load the core bitstream in SPL.
>>> So, you want 2 files periph.rbf.mkimage, and fitImage(contains
>>> core.rbf) or both periph.rbf and core.rbf in one fitImage?
>> Does it make sense ?
> Which one you refer, 1 or 2?
> 1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf) in
> FAT partition
> 2. Both periph.rbf and core.rbf in one fitImage in FAT partition

One fitImage file containing both .rbf files , stored in whatever
storage the user needs.

-- 
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/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Chee, Tien Fong]

On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote:
> On 1/4/19 1:46 AM, Chee, Tien Fong wrote:
> [...]
> 
> > 
> > > 
> > > > 
> > > > 2. What you means with partial loading? partial loading for
> > > > periph.rbf
> > > > or core.rbf or both rbfs?
> > > That you can only load the relevant image from the fitImage, not
> > > the
> > > entire fitImage, which lets you load the core bitstream in SPL.
> > So, you want 2 files periph.rbf.mkimage, and fitImage(contains
> > core.rbf) or both periph.rbf and core.rbf in one fitImage?
> Does it make sense ?
Which one you refer, 1 or 2?
1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf) in
FAT partition
2. Both periph.rbf and core.rbf in one fitImage in FAT partition
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Marek Vasut]

On 1/4/19 1:46 AM, Chee, Tien Fong wrote:
[...]

>>> 2. What you means with partial loading? partial loading for
>>> periph.rbf
>>> or core.rbf or both rbfs?
>> That you can only load the relevant image from the fitImage, not the
>> entire fitImage, which lets you load the core bitstream in SPL.
> So, you want 2 files periph.rbf.mkimage, and fitImage(contains
> core.rbf) or both periph.rbf and core.rbf in one fitImage?

Does it make sense ?

-- 
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 3/7] riscv: use invalidate/flush_*cache_range functions in cache.c

[Bin Meng]

On Fri, Jan 4, 2019 at 8:38 AM Lukas Auer
 wrote:
>
> The flush_cache() function in lib/cache.c ignores its arguments and
> flushes the complete data and instruction caches. Use the
> invalidate/flush_*cache_range() functions instead to only flush the
> requested memory region.
>
> This patch does not change the current behavior of U-Boot, since the
> implementation of the invalidate/flush_*cache_range() functions flush
> the complete data and instruction caches. It is in preparation for CPUs
> with the necessary functionality for flushing a selectable memory range.
>
> Signed-off-by: Lukas Auer 
> ---
>
> Changes in v2:
> - New patch "riscv: use invalidate/flush_*cache_range functions in
> cache.c"
>
>  arch/riscv/lib/cache.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 2/7] riscv: move the AX25-specific implementation of flush_dcache_all

[Bin Meng]

On Fri, Jan 4, 2019 at 8:38 AM Lukas Auer
 wrote:
>
> The fence instruction is used to enforce device I/O and memory ordering
> constraints in RISC-V. It can not be relied on to directly affect the
> data cache on every CPU.
> Andes' AX25 does not have a coherence agent. Its fence instruction
> flushes the data cache and is used to keep data in the system coherent.
> The implementation of flush_dcache_all in lib/cache.c is therefore
> specific to the AX25. Move it into the AX25-specific cache.c in
> cpu/ax25/.
>
> This also adds a missing new line between flush_dcache_all and
> flush_dcache_range in lib/cache.c.
>
> Signed-off-by: Lukas Auer 
> ---
>
> Changes in v2:
> - Replace patch "riscv: remove invalid dcache flush implementation" with
> new patch "riscv: move the AX25-specific implementation of
> flush_dcache_all"
>

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

Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform

[Bin Meng]

On Thu, Jan 3, 2019 at 9:39 PM Tom Rini  wrote:
>
> On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> > On 26. 12. 18 15:29, Tom Rini wrote:
> > > On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
> > >> Hi Michal,
> > >>
> > >> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek  
> > >> wrote:
> > >>>
> > >>> On 20. 12. 18 9:09, Bin Meng wrote:
> >  On Thu, Dec 20, 2018 at 3:55 PM Michal Simek  
> >  wrote:
> > >
> > > Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
> > >
> > > Signed-off-by: Michal Simek 
> > > ---
> > >
> > > Patch needs to be applied when this PR is merged.
> > > https://github.com/swarren/uboot-test-hooks/pull/21
> > >
> > > ---
> > >  .travis.yml | 8 
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/.travis.yml b/.travis.yml
> > > index 6e4b4ba0a34a..e14e6987e4cf 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -454,6 +454,14 @@ matrix:
> > >QEMU_TARGET="arm-softmmu"
> > >TEST_PY_ID="--id qemu"
> > >BUILDMAN="^zynq_zc702$"
> > > +- name: "test/py xilinx_versal_virt"
> > > +  env:
> > > +- TEST_PY_BD="xilinx_versal_virt"
> > > +  TEST_PY_TEST_SPEC="not sleep"
> > > +  QEMU_TARGET="aarch64-softmmu"
> > > +  QEMU_VERSION="v3.1.0"
> > > +  TEST_PY_ID="--id qemu"
> > > +  BUILDMAN="^xilinx_versal_virt$"
> > 
> >  Can we turn on 3.1.0 for all QEMU targets?
> > >>>
> > >>> I expected this question.
> > >>> First of all I wanted to enable an option to be able to wire whatever
> > >>> version. Even sha1 for not released version.
> > >>>
> > >>> I think we can try to test v3.1.0 qemu version for all boards but I will
> > >>> let Tom to decide is we can move or not.
> > >>>
> > >>
> > >> Yes, please try to test that. If everything is good, I see no reason
> > >> not using it.
> > >
> > > Yes, I would also like to move everyone up to v3.1.0 and also having the
> > > version we use be spelled out will help with future reproducibility.
> > >
> >
> > v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> > take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
> > I am happy to keep them on v3.0 and move the rest to v3.1 and let
> > vexpress guys to figured out what's wrong with v3.1 and configs around.
> >
> > What do you think?
>
> The error is:
>  Captured stdout setup 
> -
> +u-boot-test-reset vexpress_ca15_tc2 qemu
> qemu-system-arm: -tftp: invalid option
>
> And I guess the problem is that by v3.1.0 -tftp has been removed and we
> need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
> the other QEMU-based targets.  Can you update uboot-test-hooks (change
> .travis.yml to clone your fork of uboot-test-hooks rather than
> swarren's) to have the modern syntax?  Thanks!

I think the correct approach is to update uboot-test-hooks and send PR
to Stephen, then apply this 3.1.0 patch on the U-Boot side. We should
still have U-Boot's .travis.yml point to swarren's git repo, no?

Regards,
Bin
___
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

[Auer, Lukas]

Hi Bryan,

On Thu, 2019-01-03 at 01:44 +, Bryan O'Donoghue wrote:
> This patch imports the Linux kernel warp7 dts as at upstream kernel
> commit
> cf76c364a1e1.
> 
> The following was dropped from the incoming kernel DTS file
> 
> - {
> -   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.

This is caused by a typo in arch/arm/dts/imx7d-pinfunc.h, which lists
it as MX7D_PAD_LPSR_GPIO1_IO00__WDOD1_WDOG_B (WDOD instead of WDOG).
I am not familiar with the imx7s-warp, but other imx7 boards use the
external reset of the watchdog timer to reset the system.

Thanks,
Lukas

> 
> 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 {
> + regulator-min-microvolt = <150>;
> +

Re: [U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Chee, Tien Fong]

On Thu, 2019-01-03 at 21:14 +0100, Marek Vasut wrote:
> On 1/3/19 8:28 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2019-01-03 at 06:27 +0100, Marek Vasut wrote:
> > > 
> > > On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee 
> > > > > > > > 
> > > > > > > > This patch adds description on properties about file
> > > > > > > > name
> > > > > > > > used
> > > > > > > > for
> > > > > > > > both
> > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > >
> > > > > > > > ---
> > > > > > > >  .../fpga/altera-socfpga-a10-fpga-
> > > > > > > > mgr.txt   |   21
> > > > > > > > 
> > > > > > > >  1 files changed, 21 insertions(+), 0 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/doc/device-tree-bindings/fpga/altera-
> > > > > > > > socfpga-
> > > > > > > > a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > > > > a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > index 2fd8e7a..4552edc 100644
> > > > > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > > > > fpga-
> > > > > > > > mgr.txt
> > > > > > > > @@ -7,13 +7,34 @@ Required properties:
> > > > > > > > - The second index is for writing FPGA
> > > > > > > > configuration data.
> > > > > > > >  - resets : Phandle and reset specifier for the
> > > > > > > > device's
> > > > > > > > reset.
> > > > > > > >  - clocks : Clocks used by the device.
> > > > > > > > +- altr,bitstream : File name for FPGA peripheral raw
> > > > > > > > binary
> > > > > > > > which
> > > > > > > > is used
> > > > > > > > +      to initialize FPGA IOs, PLL, IO48
> > > > > > > > and
> > > > > > > > DDR.
> > > > > > > > +      or
> > > > > > > > +      File name for full RBF, consist of
> > > > > > > > periph
> > > > > > > > RBF
> > > > > > > > and core RBF
> > > > > > > > +- altr,bitstream-core : File name for core RBF which
> > > > > > > > contains
> > > > > > > > FPGA
> > > > > > > > design
> > > > > > > > +   which is used to program FPGA
> > > > > > > > CRAM
> > > > > > > > and
> > > > > > > > ERAM.
> > > > > > > >  
> > > > > > > >  Example:
> > > > > > > >  
> > > > > > > > +- Examples for booting with early IO release, enter
> > > > > > > > early
> > > > > > > > user
> > > > > > > > mode(periph RBF):
> > > > > > > > +
> > > > > > > > +   fpga_mgr: fpga-mgr@ffd03000 {
> > > > > > > > +   compatible = "altr,socfpga-a10-fpga-
> > > > > > > > mgr";
> > > > > > > > +   reg = <0xffd03000 0x100
> > > > > > > > +      0xffcfe400 0x20>;
> > > > > > > > +   clocks = <_mp_clk>;
> > > > > > > > +   resets = < FPGAMGR_RESET>;
> > > > > > > > +   altr,bitstream =
> > > > > > > > "ghrd_10as066n2.periph.rbf.mkimage";
> > > > > > > > +   altr,bitstream-core =
> > > > > > > > "ghrd_10as066n2.core.rbf.mkimage";
> > > > > > > What is this .mkimage format about ? Is that uImage ?
> > > > > > > Since
> > > > > > > it's
> > > > > > > two
> > > > > > > files, it could probably be bundled into fitImage instead
> > > > > > > ?
> > > > > > > 
> > > > > > What is this .mkimage format about ? Is that uImage ?
> > > > > > mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> > > > > > \"RBF\"
> > > > > > -d
> > > > > >  ghrd_10as066n2.periph.rbf
> > > > > > ghrd_10as066n2.periph.rbf.mkimage.
> > > > > > Yeah, this is uImage. The reason of using it for appending
> > > > > > the
> > > > > > header
> > > > > > contains file size and CRC checksum to the
> > > > > > ghrd_10as066n2.periph.rbf.
> > > > > > These both file size and CRC checksum are required in
> > > > > > socfpga
> > > > > > loadfs
> > > > > > driver.
> > > > > CRC32 is real weak. fitImage supports all kinds of more
> > > > > fitting
> > > > > checksum
> > > > > algorithms and more.
> > > > Okay.
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Since it's two> files, it could probably be bundled into
> > > > > > fitImage
> > > > > > instead ?
> > > > > > I assume you are saying the series fitImage implementation
> > > > > > patches
> > > > > > as i
> > > > > > had previously submitted which contains U-Boot, and FPGA
> > > > > > core
> > > > > > bitstream
> > > > > > 

Re: [U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

[Chee, Tien Fong]

On Thu, 2019-01-03 at 21:15 +0100, Marek Vasut wrote:
> On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
> > > 
> > > On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Sun, 2018-12-30 at 16:47 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > Update the default configuration file to enable the
> > > > > > necessary
> > > > > > functionality
> > > > > > to get the SoCFPGA loadfs driver support. This would enable
> > > > > > the
> > > > > > implementation of programming bitstream into FPGA from MMC.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  configs/socfpga_arria10_defconfig |8 
> > > > > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > > > > 
> > > > > > diff --git a/configs/socfpga_arria10_defconfig
> > > > > > b/configs/socfpga_arria10_defconfig
> > > > > > index 6ebda81..8158dbb 100644
> > > > > > --- a/configs/socfpga_arria10_defconfig
> > > > > > +++ b/configs/socfpga_arria10_defconfig
> > > > > > @@ -27,8 +27,16 @@
> > > > > > CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
> > > > > >  # CONFIG_EFI_PARTITION is not set
> > > > > >  CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
> > > > > >  CONFIG_ENV_IS_IN_MMC=y
> > > > > > +CONFIG_SPL_ENV_SUPPORT=y
> > > > > >  CONFIG_SPL_DM=y
> > > > > >  CONFIG_SPL_DM_SEQ_ALIAS=y
> > > > > > +CONFIG_SPL_DM_MMC=y
> > > > > > +CONFIG_SPL_MMC_SUPPORT=y
> > > > > > +CONFIG_SPL_EXT_SUPPORT=y
> > > > > > +CONFIG_SPL_FAT_SUPPORT=y
> > > > > > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> > > > > > +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> > > > > This breaks systems with large FAT clusters. Why is this
> > > > > needed
> > > > > for
> > > > > programming the FPGA from MMC ?
> > > > This is final tuning in term of getting balance between
> > > > performance
> > > > and
> > > > SPL image size for the socdk devkit. User can change that if
> > > > they
> > > > need
> > > > large FAT cluster in their design, right?
> > > I think it'd rather make sense to fix the FAT driver to avoid
> > > statically
> > > allocating those massive buffers for big clusters. I think that
> > > can
> > > be
> > > done by allocating those on stack instead ... or mallocating
> > > them.
> > I need to explore 1st as i'm not familiar with FAT driver. Or can
> > we
> > temporary keeping this patch 1st until FAT issue is separately
> > fixed?
> Please explore this, it'll be beneficial in the long run.
Okay.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] riscv: remove invalid dcache flush implementation

[Auer, Lukas]

Hi Rick,

On Thu, 2019-01-03 at 08:48 +0800, Rick Chen wrote:
> Hi Lukas
> 
> Auer, Lukas  於 2019年1月2日 週三 下午8:22寫道：
> > Hi Rick,
> > 
> > On Wed, 2019-01-02 at 10:54 +0800, Rick Chen wrote:
> > > Hi Lukas
> > > 
> > > > > From: Lukas Auer [mailto:lukas.a...@aisec.fraunhofer.de]
> > > > > Sent: Monday, December 31, 2018 2:28 AM
> > > > > To: u-boot@lists.denx.de
> > > > > Cc: Anup Patel; Lukas Auer; Rick Jian-Zhi Chen(陳建志); Bin
> > > > > Meng;
> > > > > Greentime Hu
> > > > > Subject: [PATCH 2/6] riscv: remove invalid dcache flush
> > > > > implementation
> > > > > 
> > > > > The fence instruction is used to enforce device I/O and
> > > > > memory
> > > > > ordering
> > > > > constraints in RISC-V. It does not directly affect the data
> > > > > cache
> > > > > and particular
> > > > > cannot be used to flush or invalidate it. RISC-V does not
> > > > > have
> > > > > instructions for
> > > > > explicit cache control. Remove the flush_dcache_all
> > > > > implementation and its use
> > > > > in all dcache-specific functions in lib/cache.c.
> > > > > 
> > > 
> > > The privileged mention that fence is for the purposes of
> > > ordering,
> > > but
> > > does not say
> > > it can not be used to flush or invalidate.
> > > 
> > > Andes's ax25 have no coherence agent. So it need fence
> > > instruction to
> > > manipulate
> > > cache flush or invalidate. Or there will be some data
> > > synchronization
> > > error
> > > occurs on ae350 platform.
> > > 
> > 
> > I was not aware of this. Does the ax25 flush the whole dcache on
> > any
> > fence instruction?
> 
> Yes.
> It will flush the whole dcache when execute fence.
> 
> > You are right, we can't remove it in this case. Since it is
> > specific to
> > the ax25, should I move it into cpu/ax25/cache.c instead?
> 
> OK
> It is good to me.
> And thanks for your understanding and improvements.
> 

You are welcome! I just submitted version 2 of the patch series.

Thanks,
Lukas

> Regards
> Rick
> 
> > Thanks,
> > Lukas
> > 
> > > Thanks
> > > Rick
> > > 
> > > 
> > > > > This also adds a missing new line between flush_dcache_all
> > > > > and
> > > > > flush_dcache_range in lib/cache.c.
> > > > > 
> > > > > Signed-off-by: Lukas Auer 
> > > > > ---
> > > > > This patch only removes the implementation itself and its use
> > > > > in
> > > > > dcache-specific
> > > > > functions in lib/cache.c. There are more uses of it in
> > > > > arch/riscv/, which this patch
> > > > > does not remove.
> > > > > 
> > > > >  arch/riscv/lib/cache.c | 4 +---
> > > > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> > > > > index
> > > > > ae5c60716f..203e287612 100644
> > > > > --- a/arch/riscv/lib/cache.c
> > > > > +++ b/arch/riscv/lib/cache.c
> > > > > @@ -13,11 +13,10 @@ void invalidate_icache_all(void)
> > > > > 
> > > > >  void flush_dcache_all(void)
> > > > >  {
> > > > > - asm volatile ("fence" :::"memory");
> > > > >  }
> > > > > +
> > > > >  void flush_dcache_range(unsigned long start, unsigned long
> > > > > end)  {
> > > > > - flush_dcache_all();
> > > > >  }
> > > > > 
> > > > >  void invalidate_icache_range(unsigned long start, unsigned
> > > > > long
> > > > > end) @@ -31,7
> > > > > +30,6 @@ void invalidate_icache_range(unsigned long start,
> > > > > unsigned long end)
> > > > > 
> > > > >  void invalidate_dcache_range(unsigned long start, unsigned
> > > > > long
> > > > > end)  {
> > > > > - flush_dcache_all();
> > > > >  }
> > > > > 
> > > > >  void cache_flush(void)
> > > > > --
> > > > > 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 7/7] riscv: qemu: define standalone load address

[Lukas Auer]

We need to define the standalone load address to use standalone
application on qemu-riscv. Define it and set it equal to
CONFIG_SYS_LOAD_ADDR.

To not overwrite it, change the assigned of CONFIG_STANDALONE_LOAD_ADDR
in arch/riscv/config.mk to a conditional one.

Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/config.mk | 2 +-
 include/configs/qemu-riscv.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
index e484a3f0ef..84654eb3ed 100644
--- a/arch/riscv/config.mk
+++ b/arch/riscv/config.mk
@@ -23,7 +23,7 @@ PLATFORM_LDFLAGS  += -m $(64bit-emul)
 EFI_LDS:= elf_riscv64_efi.lds
 endif
 
-CONFIG_STANDALONE_LOAD_ADDR = 0x
+CONFIG_STANDALONE_LOAD_ADDR ?= 0x
 
 PLATFORM_CPPFLAGS  += -ffixed-gp -fpic
 PLATFORM_RELFLAGS  += -fno-common -gdwarf-2 -ffunction-sections \
diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
index b29d155d09..2588c5a0b2 100644
--- a/include/configs/qemu-riscv.h
+++ b/include/configs/qemu-riscv.h
@@ -17,6 +17,8 @@
 
 #define CONFIG_SYS_BOOTM_LEN   SZ_16M
 
+#define CONFIG_STANDALONE_LOAD_ADDR0x8020
+
 /* Environment options */
 #define CONFIG_ENV_SIZESZ_4K
 
-- 
2.20.1

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

[U-Boot] [PATCH v2 6/7] riscv: support standalone applications on RV64I systems

[Lukas Auer]

Add an implementation of EXPORT_FUNC() for RV64I systems to support them
in standalone applications.

Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---

Changes in v2: None

 examples/standalone/stubs.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index f37d209da6..0827bde35e 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -176,6 +176,16 @@ gd_t *global_data;
 /*
  * gp holds the pointer to the global_data. t0 is call clobbered.
  */
+#ifdef CONFIG_ARCH_RV64I
+#define EXPORT_FUNC(f, a, x, ...)  \
+   asm volatile (  \
+"  .globl " #x "\n"\
+#x ":\n"   \
+"  ld  t0, %0(gp)\n"   \
+"  ld  t0, %1(t0)\n"   \
+"  jr  t0\n"   \
+   : : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "t0");
+#else
 #define EXPORT_FUNC(f, a, x, ...)  \
asm volatile (  \
 "  .globl " #x "\n"\
@@ -184,6 +194,7 @@ gd_t *global_data;
 "  lw  t0, %1(t0)\n"   \
 "  jr  t0\n"   \
: : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "t0");
+#endif
 #elif defined(CONFIG_ARC)
 /*
  * r25 holds the pointer to the global_data. r10 is call clobbered.
-- 
2.20.1

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

[U-Boot] [PATCH v2 5/7] riscv: replace use of callee-saved register in standalone

[Lukas Auer]

Register x19 (s3) is a callee-saved register. It must not be used to
load and jump to exported functions without saving it beforehand.
Replace it with t0, a temporary and caller-saved register.

Change the code comment to reflect this and fix it to correctly list gp
as the register with the pointer to global data.

Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---

Changes in v2: None

 examples/standalone/stubs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index fadde669fa..f37d209da6 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -174,16 +174,16 @@ gd_t *global_data;
: : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "$r16");
 #elif defined(CONFIG_RISCV)
 /*
- * t7 holds the pointer to the global_data. gp is call clobbered.
+ * gp holds the pointer to the global_data. t0 is call clobbered.
  */
 #define EXPORT_FUNC(f, a, x, ...)  \
asm volatile (  \
 "  .globl " #x "\n"\
 #x ":\n"   \
-"  lw  x19, %0(gp)\n"  \
-"  lw  x19, %1(x19)\n" \
-"  jr  x19\n"  \
-   : : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "x19");
+"  lw  t0, %0(gp)\n"   \
+"  lw  t0, %1(t0)\n"   \
+"  jr  t0\n"   \
+   : : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "t0");
 #elif defined(CONFIG_ARC)
 /*
  * r25 holds the pointer to the global_data. r10 is call clobbered.
-- 
2.20.1

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

[U-Boot] [PATCH v2 4/7] riscv: remove RISC-V standalone linker script

[Lukas Auer]

Standalone applications do not require a separate linker script and can
use the default linker script of the compiler instead. Remove the RISC-V
standalone linker script.

Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/config.mk  |  1 -
 examples/standalone/riscv.lds | 40 ---
 2 files changed, 41 deletions(-)
 delete mode 100644 examples/standalone/riscv.lds

diff --git a/arch/riscv/config.mk b/arch/riscv/config.mk
index ff4fe64001..e484a3f0ef 100644
--- a/arch/riscv/config.mk
+++ b/arch/riscv/config.mk
@@ -24,7 +24,6 @@ EFI_LDS   := elf_riscv64_efi.lds
 endif
 
 CONFIG_STANDALONE_LOAD_ADDR = 0x
-LDFLAGS_STANDALONE += -T $(srctree)/examples/standalone/riscv.lds
 
 PLATFORM_CPPFLAGS  += -ffixed-gp -fpic
 PLATFORM_RELFLAGS  += -fno-common -gdwarf-2 -ffunction-sections \
diff --git a/examples/standalone/riscv.lds b/examples/standalone/riscv.lds
deleted file mode 100644
index 9a25861052..00
--- a/examples/standalone/riscv.lds
+++ /dev/null
@@ -1,40 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Copyright (C) 2017 Andes Technology Corporation
- * Rick Chen, Andes Technology Corporation 
- */
-
-OUTPUT_ARCH(riscv)
-ENTRY(_start)
-SECTIONS
-{
-. = ALIGN(4);
-.text :
-{
-*(.text)
-}
-
-. = ALIGN(4);
-.data : {
-   __global_pointer$ = . + 0x800;
-   *(.data)
-   }
-
-. = ALIGN(4);
-
-.got : {
-__got_start = .;
-*(.got)
-__got_end = .;
-}
-
- . = ALIGN(4);
-__bss_start = .;
-.bss : { *(.bss) }
-__bss_end = .;
-
-. = ALIGN(4);
-.rela.text : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
-
-_end = .;
-}
-- 
2.20.1

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

[U-Boot] [PATCH v2 2/7] riscv: move the AX25-specific implementation of flush_dcache_all

[Lukas Auer]

The fence instruction is used to enforce device I/O and memory ordering
constraints in RISC-V. It can not be relied on to directly affect the
data cache on every CPU.
Andes' AX25 does not have a coherence agent. Its fence instruction
flushes the data cache and is used to keep data in the system coherent.
The implementation of flush_dcache_all in lib/cache.c is therefore
specific to the AX25. Move it into the AX25-specific cache.c in
cpu/ax25/.

This also adds a missing new line between flush_dcache_all and
flush_dcache_range in lib/cache.c.

Signed-off-by: Lukas Auer 
---

Changes in v2:
- Replace patch "riscv: remove invalid dcache flush implementation" with
new patch "riscv: move the AX25-specific implementation of
flush_dcache_all"

 arch/riscv/cpu/ax25/cache.c | 22 ++
 arch/riscv/lib/cache.c  | 10 --
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
index 8d6ae170b8..228fc55f56 100644
--- a/arch/riscv/cpu/ax25/cache.c
+++ b/arch/riscv/cpu/ax25/cache.c
@@ -6,6 +6,28 @@
 
 #include 
 
+void flush_dcache_all(void)
+{
+   /*
+* Andes' AX25 does not have a coherence agent. U-Boot must use data
+* cache flush and invalidate functions to keep data in the system
+* coherent.
+* The implementation of the fence instruction in the AX25 flushes the
+* data cache and is used for this purpose.
+*/
+   asm volatile ("fence" ::: "memory");
+}
+
+void flush_dcache_range(unsigned long start, unsigned long end)
+{
+   flush_dcache_all();
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long end)
+{
+   flush_dcache_all();
+}
+
 void icache_enable(void)
 {
 #ifndef CONFIG_SYS_ICACHE_OFF
diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
index ae5c60716f..78b19da2c5 100644
--- a/arch/riscv/lib/cache.c
+++ b/arch/riscv/lib/cache.c
@@ -11,13 +11,12 @@ void invalidate_icache_all(void)
asm volatile ("fence.i" ::: "memory");
 }
 
-void flush_dcache_all(void)
+__weak void flush_dcache_all(void)
 {
-   asm volatile ("fence" :::"memory");
 }
-void flush_dcache_range(unsigned long start, unsigned long end)
+
+__weak void flush_dcache_range(unsigned long start, unsigned long end)
 {
-   flush_dcache_all();
 }
 
 void invalidate_icache_range(unsigned long start, unsigned long end)
@@ -29,9 +28,8 @@ void invalidate_icache_range(unsigned long start, unsigned 
long end)
invalidate_icache_all();
 }
 
-void invalidate_dcache_range(unsigned long start, unsigned long end)
+__weak void invalidate_dcache_range(unsigned long start, unsigned long end)
 {
-   flush_dcache_all();
 }
 
 void cache_flush(void)
-- 
2.20.1

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

[U-Boot] [PATCH v2 3/7] riscv: use invalidate/flush_*cache_range functions in cache.c

[Lukas Auer]

The flush_cache() function in lib/cache.c ignores its arguments and
flushes the complete data and instruction caches. Use the
invalidate/flush_*cache_range() functions instead to only flush the
requested memory region.

This patch does not change the current behavior of U-Boot, since the
implementation of the invalidate/flush_*cache_range() functions flush
the complete data and instruction caches. It is in preparation for CPUs
with the necessary functionality for flushing a selectable memory range.

Signed-off-by: Lukas Auer 
---

Changes in v2:
- New patch "riscv: use invalidate/flush_*cache_range functions in
cache.c"

 arch/riscv/lib/cache.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
index 78b19da2c5..5437a122a1 100644
--- a/arch/riscv/lib/cache.c
+++ b/arch/riscv/lib/cache.c
@@ -40,8 +40,8 @@ void cache_flush(void)
 
 void flush_cache(unsigned long addr, unsigned long size)
 {
-   invalidate_icache_all();
-   flush_dcache_all();
+   invalidate_icache_range(addr, addr + size);
+   flush_dcache_range(addr, addr + size);
 }
 
 __weak void icache_enable(void)
-- 
2.20.1

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

[U-Boot] [PATCH v2 0/7] Small fixes for RISC-V

[Lukas Auer]

This patch series contains small fixes for RISC-V. It touches three
areas.

- Patch 1 clarifies the error message on undefined exceptions.
- Patch 2 removes the current dcache flush implementation. It uses the
fence instruction, which does not directly affect the data cache and can
therefore not be used to implement dcache flush and invalidation.
- Patches 3-6 improve support for standalone applications. They add
support for RV64I systems and fix a problem, where a callee-saved
register is used without saving it beforehand. Patch 6 defines the
standalone load address for qemu-riscv to allow it to run standalone
applications.

Changes in v2:
- Replace patch "riscv: remove invalid dcache flush implementation" with
new patch "riscv: move the AX25-specific implementation of
flush_dcache_all"
- New patch "riscv: use invalidate/flush_*cache_range functions in
cache.c"

Lukas Auer (7):
  riscv: clarify error message on undefined exceptions
  riscv: move the AX25-specific implementation of flush_dcache_all
  riscv: use invalidate/flush_*cache_range functions in cache.c
  riscv: remove RISC-V standalone linker script
  riscv: replace use of callee-saved register in standalone
  riscv: support standalone applications on RV64I systems
  riscv: qemu: define standalone load address

 arch/riscv/config.mk  |  3 +--
 arch/riscv/cpu/ax25/cache.c   | 22 +++
 arch/riscv/lib/cache.c| 14 ++--
 arch/riscv/lib/interrupts.c   |  3 ++-
 examples/standalone/riscv.lds | 40 ---
 examples/standalone/stubs.c   | 21 +-
 include/configs/qemu-riscv.h  |  2 ++
 7 files changed, 49 insertions(+), 56 deletions(-)
 delete mode 100644 examples/standalone/riscv.lds

-- 
2.20.1

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

[U-Boot] [PATCH v2 1/7] riscv: clarify error message on undefined exceptions

[Lukas Auer]

Undefined exceptions are treated as reserved. This is not clearly
communicated to the user. Adjust the error message to clarify that a
reserved exception has occurred and add additional details.

Fixes: e8b522b ("riscv: treat undefined exception codes as reserved")
Signed-off-by: Lukas Auer 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/lib/interrupts.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index e185933b01..74c1e561c7 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -37,7 +37,8 @@ static void _exit_trap(ulong code, ulong epc, struct pt_regs 
*regs)
printf("exception code: %ld , %s , epc %lx , ra %lx\n",
   code, exception_code[code], epc, regs->ra);
} else {
-   printf("Reserved\n");
+   printf("reserved exception code: %ld , epc %lx , ra %lx\n",
+  code, epc, regs->ra);
}
 
hang();
-- 
2.20.1

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

[U-Boot] [V2] please pull u-boot-samsung master

[Minkyu Kang]

Hi,

The following changes since commit 1f2e948d6d53f77a2ddb2dde3531b0d5bc2815ad:

  Prepare v2019.01-rc2 (2018-12-17 20:25:24 -0500)

are available in the git repository at:

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

for you to fetch changes up to 2a195703d6e62172e532ffae05a79e9d12f602bc:

  exynos: allow SPL to build in thumb mode (2019-01-03 09:37:18 +0900)


Anand Moon (2):
  exynos5-dt-types: add missing dtb file for Odroid HC1/HC2
  odroid: Update README.odroid for support of Odroid HC1

Guillaume GARDET (2):
  exynos: imply SYS_THUMB_BUILD
  exynos: allow SPL to build in thumb mode

Seung-Woo Kim (1):
  Revert "arm: config: fix default console only to specify the device"

 arch/arm/Kconfig   | 1 +
 arch/arm/mach-exynos/include/mach/system.h | 3 ++-
 doc/README.odroid  | 7 +--
 include/configs/odroid.h   | 4 ++--
 include/configs/odroid_xu3.h   | 5 +++--
 include/configs/s5p_goni.h | 4 ++--
 include/configs/s5pc210_universal.h| 4 ++--
 include/configs/trats.h| 4 ++--
 include/configs/trats2.h   | 4 ++--
 9 files changed, 21 insertions(+), 15 deletions(-)
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] exynos: allow SPL to build in thumb mode

[Minkyu Kang]

On 02/01/19 22:31, Guillaume GARDET wrote:
> Building peach-pi smdk5420 and peach-pit with thumb mode for SPL
> ends-up in the following error:
> 
> Error: Thumb encoding does not support an immediate here -- `msr 
> cpsr_c,#0x13|0xC0'
> 
> Use an intermediate register to be able to use thumb for exynos5 SPL.
> 
> 
> Signed-off-by: Guillaume GARDET 
> 
> Cc: Albert Aribaud 
> Cc: Minkyu Kang 
> Cc: Tom Rini 
> 
> ---
>  arch/arm/mach-exynos/include/mach/system.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-exynos/include/mach/system.h 
> b/arch/arm/mach-exynos/include/mach/system.h
> index 4837781957..81fa9800b4 100644
> --- a/arch/arm/mach-exynos/include/mach/system.h
> +++ b/arch/arm/mach-exynos/include/mach/system.h
> @@ -58,7 +58,8 @@ struct exynos5_sysreg {
>  /* Move 0xd3 value to CPSR register to enable SVC mode */
>  #define svc32_mode_en() __asm__ __volatile__ \
>   ("@ I disable, Mode: 0x13 - SVC\n\t"  \
> -  "msr cpsr_c, #0x13|0xC0\n\t" : : )
> +  "mov r0, #0x13|0xC0\n\t"   \
> +  "msr cpsr_c, r0\n\t" : : )
>  
>  /* Set program counter with the given value */
>  #define set_pc(x) __asm__ __volatile__ ("mov pc, %0\n\t" : : "r"(x))
> 

applied to u-boot-samsung.

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

Re: [U-Boot] [PATCH] Kconfig: don't pollute Kconfig w/ i.MX8M options for everyone

[Philipp Tomsich]

> On 03.01.2019, at 21:21, Tom Rini  wrote:
> 
> On Thu, Jan 03, 2019 at 06:47:40PM +0100, Philipp Tomsich wrote:
> 
>> No point in showing the various DRAM options (right in the top-level
>> menu for 'Device Drivers') for i.MX8M when configured for a different
>> architecture.  This wraps an 'if ARCH_IMX8M' around these.
>> 
>> Signed-off-by: Philipp Tomsich 
>> ---
>> 
>> drivers/ddr/imx/Kconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/ddr/imx/Kconfig b/drivers/ddr/imx/Kconfig
>> index 7e06fb2..09a35e5 100644
>> --- a/drivers/ddr/imx/Kconfig
>> +++ b/drivers/ddr/imx/Kconfig
>> @@ -1 +1,3 @@
>> +if ARCH_IMX8M
>> source "drivers/ddr/imx/imx8m/Kconfig"
>> +endif
> 
> Ugh.  We need drivers/ddr/imx/imx8m/Kconfig to have real 'depends on'
> lines like all of the other DDR controllers.

Unfortunately, there’s more without meaningful 'depends on’: STM32_SDRAM and
MPC83XX_SDRAM also caught my eye today (I went into menuconfig for the first
time in a long time)—they just didn’t bother me as much as this one ;-)

If I remember to do so, I’ll submit patches for those two as well ...

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

Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms

[Marek Vasut]

On 1/3/19 10:47 PM, Lukasz Majewski wrote:
> On Fri, 4 Jan 2019 01:23:17 +0530
> Jagan Teki  wrote:
> 
>> On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski  wrote:
>>>
>>> Hi Jagan,
>>>  
 On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot
  wrote:  
>
>
> On 29/12/2018 19:49, Jagan Teki wrote:  
>> On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
>>  wrote:  
>>> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
>>>  wrote: Better to have proper commit head
>>> that tells the real issue.  
>
> I found it hard to come up with a short description of the real
> issue.
>
> At least this title makes it clear that it is a regression fix,
> not a new feature.
>
> The details of the failures  are in the commit log (or so I
> thought) 
>>>  
 Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID
 for USB gadget devices")

 The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to
 be declared even for platforms that do not enable
 DM_USB_GADGET. Otherwise the driver for their usb
 peripheral controller fails to bind.  
>>> Sorry this is unclear, you are trying to skip DM_USB_GADGET
>>> code even though UCLASS_USB_GADGET_GENERIC id used. does it
>>> make sense?  
>
> Sorry for the delay. This was indeed a vacation time.
>
> This patch does not skip DM_USB_GADGET. What it does is declare
> the UCLASS_DRIVER for USB peripheral devices even if
> DM_USB_GADGET is not set.
>
> DM_USB_GADGET is a new option and not (yet) widely used and some
> drivers have their own version of the DM support for gadget
> drivers (ie they implement their own version of
> usb_gadget_initialize(), usb_gadget_release() and
> usb_gadget_handle_interrupts()). However all those drivers use
> the UCLASS_USB_GADGET_GENERIC uclass ID and thus the
> UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared.
> In the past they used UCLASS_USB_DEV_GENERIC, but this option
> is intended for the host side.  

 Acked-by: Jagan Teki 

 Marek, any comments?  
>>>
>>> Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
>>> which also includes some other fixes.  
>>
>> Please don't miss this, sunxi need this fix.
> 
> I'm now running build tests on this and Sam's patches. I will prepare
> PR and send it to Marek or Tom (if Marek is overloaded).

It is still unclear what you wanted me to comment on.

And you know where to send the PR - u-boot-usb.

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

Re: [U-Boot] [PATCH] imx6q_logic: Enable MMC booting from SPL

[Lukasz Majewski]

Hi Adam,

> On Thu, Dec 27, 2018 at 10:53 AM Adam Ford  wrote:
> >
> > The MMC booting wasn't previously fitting into the codespace.
> > This patch enables MMC booting from the baseboard by reducing
> > some DM overhead during SPL.
> >  
> 
> I'm going to NAK my own work because I found some bugs after I
> re-based on master, so I'm going to rework a few things.
> Sorry for the noise.

I've made a move to make one imx6q based board to support DM/DTS in
both SPL and u-boot proper.

Maybe, instead of adding new pinmux definitions to SPL, you would like
to look into pinctrl driver (and give some feedback/improvement)?

http://patchwork.ozlabs.org/cover/1019842/

> 
> adam
> > Signed-off-by: Adam Ford 
> >
> > diff --git a/board/logicpd/imx6/imx6logic.c
> > b/board/logicpd/imx6/imx6logic.c index ce1c8a5d6b..696f5c4183 100644
> > --- a/board/logicpd/imx6/imx6logic.c
> > +++ b/board/logicpd/imx6/imx6logic.c
> > @@ -60,6 +60,7 @@ static iomux_v3_cfg_t const uart3_pads[] = {
> > MX6_PAD_EIM_EB3__UART3_RTS_B | MUX_PAD_CTRL(UART_PAD_CTRL),
> >  };
> >
> > +#ifndef CONFIG_SPL_BUILD
> >  static void fixup_enet_clock(void)
> >  {
> > struct iomuxc *iomuxc_regs = (struct iomuxc
> > *)IOMUXC_BASE_ADDR; @@ -108,6 +109,7 @@ static void
> > fixup_enet_clock(void) dm_gpio_set_value(, 1);
> > mdelay(50);
> >  }
> > +#endif
> >
> >  static void setup_iomux_uart(void)
> >  {
> > @@ -158,7 +160,9 @@ int overwrite_console(void)
> >
> >  int board_early_init_f(void)
> >  {
> > +#ifndef CONFIG_SPL_BUILD
> > fixup_enet_clock();
> > +#endif
> > setup_iomux_uart();
> > setup_nand_pins();
> > return 0;
> > @@ -200,6 +204,74 @@ int spl_start_uboot(void)
> >  }
> >  #endif
> >
> > +/* SD interface */
> > +#define
> > USDHC_PAD_CTRL \
> > +   (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm
> > |   \
> > +PAD_CTL_SRE_FAST | PAD_CTL_HYS)
> > +
> > +static iomux_v3_cfg_t const usdhc1_pads[] = {
> > +   MX6_PAD_SD1_CLK__SD1_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD1_CMD__SD1_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD1_DAT0__SD1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD1_DAT1__SD1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD1_DAT2__SD1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD1_DAT3__SD1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +};
> > +
> > +static iomux_v3_cfg_t const usdhc2_pads[] = {
> > +   MX6_PAD_SD2_DAT0__SD2_DATA0 |
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD2_DAT1__SD2_DATA1 |
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD2_DAT2__SD2_DATA2 |
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD2_DAT3__SD2_DATA3 |
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD2_CLK__SD2_CLK|
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_SD2_CMD__SD2_CMD|
> > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > +   MX6_PAD_GPIO_4__GPIO1_IO04  |
> > MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ +};
> > +
> > +#ifdef CONFIG_FSL_ESDHC
> > +struct fsl_esdhc_cfg usdhc_cfg[] = {
> > +   {USDHC1_BASE_ADDR}, /* SOM */
> > +   {USDHC2_BASE_ADDR}  /* Baseboard */
> > +};
> > +
> > +int board_mmc_init(bd_t *bis)
> > +{
> > +   struct src *psrc = (struct src *)SRC_BASE_ADDR;
> > +   unsigned int reg = readl(>sbmr1) >> 11;
> > +   /*
> > +* Upon reading BOOT_CFG register the following map is done:
> > +* Bit 11 and 12 of BOOT_CFG register can determine the
> > current
> > +* mmc port
> > +* 0x1  SD1-SOM
> > +* 0x2  SD2-Baseboard
> > +*/
> > +
> > +   reg &= 0x3; /* Only care about bottom 2 bits */
> > +
> > +   switch (reg - 1) {
> > +   case 0:
> > +   SETUP_IOMUX_PADS(usdhc1_pads);
> > +   usdhc_cfg[0].esdhc_base = USDHC1_BASE_ADDR;
> > +   usdhc_cfg[0].sdhc_clk =
> > mxc_get_clock(MXC_ESDHC_CLK);
> > +   gd->arch.sdhc_clk = usdhc_cfg[0].sdhc_clk;
> > +   break;
> > +   case 1:
> > +   SETUP_IOMUX_PADS(usdhc2_pads);
> > +   usdhc_cfg[1].esdhc_base = USDHC2_BASE_ADDR;
> > +   usdhc_cfg[1].sdhc_clk =
> > mxc_get_clock(MXC_ESDHC2_CLK);
> > +   gd->arch.sdhc_clk = usdhc_cfg[1].sdhc_clk;
> > +   break;
> > +   }
> > +
> > +   return fsl_esdhc_initialize(bis, _cfg[reg - 1]);
> > +}
> > +
> > +int board_mmc_getcd(struct mmc *mmc)
> > +{
> > +   return 1;
> > +}
> > +#endif
> > +
> >  static void ccgr_init(void)
> >  {
> > struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg
> > *)CCM_BASE_ADDR; diff --git a/configs/imx6q_logic_defconfig
> > b/configs/imx6q_logic_defconfig index 036069a437..d0362665bb 100644
> > --- a/configs/imx6q_logic_defconfig
> > +++ b/configs/imx6q_logic_defconfig
> > @@ -4,25 +4,25 @@ CONFIG_SYS_TEXT_BASE=0x1780
> >  

Re: [U-Boot] Booting on RK3399

[Simon Glass]

Hi Mark,

On Thu, 3 Jan 2019 at 04:23, Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Wed, 2 Jan 2019 20:37:45 -0700
> >
> > > Haven't tested flashing eMMC with rkdeveloptool myself, but that
> > > should work on the firefly as well.
> > >
> > > Another complication as that the serial console speed defaults to
> > > 150 which isn't supported by all serial-to-USB chips and frankly
> >
> > Yes I seem to have one that supports this, so this is fine.
>
> Just be aware that you'll need to patch TF-A to configure the serial
> port to 150 as well.  Probably just a matter of changing
> RK3399_BAUDRATE in plat/rockchip/rk3399/rk3399_def.h.

OK, did that.
Here are the results:

v2018.01
U-Boot SPL board init"Synchronous Abort" handler, esr 0x0007
ELR: e203a891a6e4
"Synchronous Abort" handler, esr 0x

v2018.03
U-Boot SPL board init"Synchronous Abort" handler, esr 0x
elr: ff8ca6fc lr : a7bc
"Synchronous Abort" handler, esr 0x

v2018.05
U-Boot SPL board init"Synchronous Abort" handler, esr 0x0007
elr: ff8ca7a4 lr : ff8ca864
"Synchronous Abort" handler, esr 0x

v2018.07
U-Boot SPL board init"Synchronous Abort" handler, esr 0xff00
elr: ff8ca8f0 lr : ff8ca9b0
"Synchronous Abort" handler, esr 0x

v2018.09
U-Boot SPL board init
(no more output)

mainline:
U-Boot SPL board init
(no more output)


It died when I call printf() at the start of board_init_r(). If I put
printf() anywhere inside spl_relocate_stack_gd() it is happy. Also
putc() works OK. So perhaps the code that calls that function is doing
something wrong? Some sort of stack problem?

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

Re: [U-Boot] [PATCH 0/6] Add support for loading FPGA bitstream

[Marek Vasut]

On 1/3/19 6:33 AM, Chee, Tien Fong wrote:
> On Tue, 2019-01-01 at 21:36 +0100, Marek Vasut wrote:
>> On 1/1/19 3:52 AM, Chee, Tien Fong wrote:
>>>
>>> On Sun, 2018-12-30 at 16:44 +0100, Marek Vasut wrote:

 On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee 
>
> These series of patches enable peripheral bitstream being
> programmed into FPGA
> to get the DDR up running. This's also called early IO release,
> because the
> peripheral bitstream is only initializing FPGA IOs, PLL, IO48
> and
> DDR.
>
> Once DDR is up running, core bitstream from MMC which contains
> user
> FPGA
> design would be loaded into DDR location. socfpga loadfs would
> be
> called to
> program core bitstream into FPGA and entering user mode.
>
> Lastly, u-boot-dtb.img from MMC FAT partition would be loaded
> to
> DDR, and up
> running from there.
>
> For this whole mechanism to work, the SDMMC flash layout would
> be
> designed as
> shown in below:
>
> RAW partition:
> 1. spl_w_dtb-mkpimage.bin
> mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl-
> dtb.bin
>  spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-
> dtb.bin
>
> FAT partition contains:
> Bitstreams
> --
> Early IO release method is recommended for the sake of
> performance,
> improve
> up to 86% compare to full RBF.
>
> 1. ghrd_10as066n2.periph.rbf.mkimage
> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> \"RBF\"
> -d
>  ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage
>
> 2. ghrd_10as066n2.core.rbf.mkimage
> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> \"RBF\"
> -d
>  ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
>
> OR
>
> 1. ghrd_10as066n2.rbf.mkimage (full RBF)
> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> \"RBF\"
> -d
>  ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
>
> U-Boot image
> 
> 3. u-boot-dtb.img
>
> For the testing purpose, these two patches are required to
> apply
> 1st before
> applying this series of patches.
> 1. [U-Boot] [PATCH] misc: fs_loader: Switching private data
> allocation to DM
>    auto allocation
>    https://www.mail-archive.com/u-boot@lists.denx.de/msg308954.
> html
>    Reviewed-by: Simon Glass 
>
> 2. [U-Boot] [PATCH v2] Add support for initializing MMC
>    https://www.mail-archive.com/u-boot@lists.denx.de/msg310532.
> html
>    Version 2 under review.
 The above should be made into documentation, since cover letters
 are
 dropped.
>>> Happy new year Marek.
>> Happy New Year to you too.
>>
>>>
>>> Yeah, the document would be sent out once the implementation is
>>> finalized. Hence, we need your mercy and help to get this done :-P,
>>> just kidding.
>> I hope you can wrap this into V7 .
> Sure.

Thanks

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

Re: [U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

[Marek Vasut]

On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
> On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
>> On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
>>>
>>> On Sun, 2018-12-30 at 16:47 +0100, Marek Vasut wrote:

 On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
>
>
> From: Tien Fong Chee 
>
> Update the default configuration file to enable the necessary
> functionality
> to get the SoCFPGA loadfs driver support. This would enable the
> implementation of programming bitstream into FPGA from MMC.
>
> Signed-off-by: Tien Fong Chee 
> ---
>  configs/socfpga_arria10_defconfig |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/configs/socfpga_arria10_defconfig
> b/configs/socfpga_arria10_defconfig
> index 6ebda81..8158dbb 100644
> --- a/configs/socfpga_arria10_defconfig
> +++ b/configs/socfpga_arria10_defconfig
> @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>  # CONFIG_EFI_PARTITION is not set
>  CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_SPL_ENV_SUPPORT=y
>  CONFIG_SPL_DM=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_SPL_DM_MMC=y
> +CONFIG_SPL_MMC_SUPPORT=y
> +CONFIG_SPL_EXT_SUPPORT=y
> +CONFIG_SPL_FAT_SUPPORT=y
> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 This breaks systems with large FAT clusters. Why is this needed
 for
 programming the FPGA from MMC ?
>>> This is final tuning in term of getting balance between performance
>>> and
>>> SPL image size for the socdk devkit. User can change that if they
>>> need
>>> large FAT cluster in their design, right?
>> I think it'd rather make sense to fix the FAT driver to avoid
>> statically
>> allocating those massive buffers for big clusters. I think that can
>> be
>> done by allocating those on stack instead ... or mallocating them.
> I need to explore 1st as i'm not familiar with FAT driver. Or can we
> temporary keeping this patch 1st until FAT issue is separately fixed?

Please explore this, it'll be beneficial in the long run.

-- 
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/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Marek Vasut]

On 1/3/19 8:28 AM, Chee, Tien Fong wrote:
> On Thu, 2019-01-03 at 06:27 +0100, Marek Vasut wrote:
>> On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
>>>
>>> On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:

 On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
>
>
> On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
>>
>>
>> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>>
>>> From: Tien Fong Chee 
>>>
>>> This patch adds description on properties about file name
>>> used
>>> for
>>> both
>>> peripheral bitstream and core bitstream.
>>>
>>> Signed-off-by: Tien Fong Chee 
>>> ---
>>>  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |   21
>>> 
>>>  1 files changed, 21 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
>>> a10-
>>> fpga-
>>> mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>> fpga-
>>> mgr.txt
>>> index 2fd8e7a..4552edc 100644
>>> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>> fpga-
>>> mgr.txt
>>> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>> fpga-
>>> mgr.txt
>>> @@ -7,13 +7,34 @@ Required properties:
>>> - The second index is for writing FPGA
>>> configuration data.
>>>  - resets : Phandle and reset specifier for the
>>> device's
>>> reset.
>>>  - clocks : Clocks used by the device.
>>> +- altr,bitstream : File name for FPGA peripheral raw
>>> binary
>>> which
>>> is used
>>> +      to initialize FPGA IOs, PLL, IO48 and
>>> DDR.
>>> +      or
>>> +      File name for full RBF, consist of
>>> periph
>>> RBF
>>> and core RBF
>>> +- altr,bitstream-core : File name for core RBF which
>>> contains
>>> FPGA
>>> design
>>> +   which is used to program FPGA CRAM
>>> and
>>> ERAM.
>>>  
>>>  Example:
>>>  
>>> +- Examples for booting with early IO release, enter early
>>> user
>>> mode(periph RBF):
>>> +
>>> +   fpga_mgr: fpga-mgr@ffd03000 {
>>> +   compatible = "altr,socfpga-a10-fpga-mgr";
>>> +   reg = <0xffd03000 0x100
>>> +      0xffcfe400 0x20>;
>>> +   clocks = <_mp_clk>;
>>> +   resets = < FPGAMGR_RESET>;
>>> +   altr,bitstream =
>>> "ghrd_10as066n2.periph.rbf.mkimage";
>>> +   altr,bitstream-core =
>>> "ghrd_10as066n2.core.rbf.mkimage";
>> What is this .mkimage format about ? Is that uImage ? Since
>> it's
>> two
>> files, it could probably be bundled into fitImage instead ?
>>
> What is this .mkimage format about ? Is that uImage ?
> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
> \"RBF\"
> -d
>  ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
> Yeah, this is uImage. The reason of using it for appending the
> header
> contains file size and CRC checksum to the
> ghrd_10as066n2.periph.rbf.
> These both file size and CRC checksum are required in socfpga
> loadfs
> driver.
 CRC32 is real weak. fitImage supports all kinds of more fitting
 checksum
 algorithms and more.
>>> Okay.


>
>
> Since it's two> files, it could probably be bundled into
> fitImage
> instead ?
> I assume you are saying the series fitImage implementation
> patches
> as i
> had previously submitted which contains U-Boot, and FPGA core
> bitstream
> in fitImage.
 No, just bundle the bitstream in a fitImage if it's multiple
 files
 and
 if it makes sense.
>>> I need to explore 1st what's already supported in mainstream for
>>> loading bitstream in a fitImage. That's would be good if you have
>>> ideas
>>> and details of implementation to share out.


>
>
> core bitstream can be bundled into fitImage, with the file
> name as ghrd_10as066n2.core.rbf, without mkimage, so this
> bitstream
> would be loadded into DDR with function fpga load instead of
> fpga
> loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file
> required
> for
> getting DDR up 1st before loading fitImage.
 Does that mean you only need to load one of the files (you can do
 that
 with fitImage too) ? But then, what's the point of specifying
 both in
 the DT if only one is needed ?
>>> Here is the description of the flow based on the previous submitted
>>> series patches for setting up the DDR with
>>> periph.rbf.mkimage(standalone file), then followed by the core.rbf
>>> in
>>> fitImage loading into DDR for programming user design into FPGA.
>>> The
>>> implementation of loading core.rbf in fitImage into DDR is already

[U-Boot] [PATCH] ARM: imx: fix: Provide correct enum values for ONENAND/NOR boot recognition

[Lukasz Majewski]

According to "Table 5-1. Boot Device Select" (page 335,
i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 4, 09/2017)
the BOOT_CFG1[3] have following values (regarding EIM booting):
0 - NOR flash and 1 - ONENAND

This commit provides correct identification of the boot medium for IMX6Q
boards booting from NOR memory (MCCMON6 is one of them).

Signed-off-by: Lukasz Majewski 

---

 arch/arm/include/asm/mach-imx/sys_proto.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 8d6832a331..d0f866b630 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -67,8 +67,8 @@ enum imx6_bmode_serial_rom {
 };
 
 enum imx6_bmode_emi {
-   IMX6_BMODE_ONENAND,
IMX6_BMODE_NOR,
+   IMX6_BMODE_ONENAND,
 };
 
 enum imx6_bmode {
-- 
2.11.0

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

Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms

[Lukasz Majewski]

On Fri, 4 Jan 2019 01:23:17 +0530
Jagan Teki  wrote:

> On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski  wrote:
> >
> > Hi Jagan,
> >  
> > > On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot
> > >  wrote:  
> > > >
> > > >
> > > > On 29/12/2018 19:49, Jagan Teki wrote:  
> > > > > On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
> > > > >  wrote:  
> > > > >> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
> > > > >>  wrote: Better to have proper commit head
> > > > >> that tells the real issue.  
> > > >
> > > > I found it hard to come up with a short description of the real
> > > > issue.
> > > >
> > > > At least this title makes it clear that it is a regression fix,
> > > > not a new feature.
> > > >
> > > > The details of the failures  are in the commit log (or so I
> > > > thought) 
> > > > >>  
> > > > >>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID
> > > > >>> for USB gadget devices")
> > > > >>>
> > > > >>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to
> > > > >>> be declared even for platforms that do not enable
> > > > >>> DM_USB_GADGET. Otherwise the driver for their usb
> > > > >>> peripheral controller fails to bind.  
> > > > >> Sorry this is unclear, you are trying to skip DM_USB_GADGET
> > > > >> code even though UCLASS_USB_GADGET_GENERIC id used. does it
> > > > >> make sense?  
> > > >
> > > > Sorry for the delay. This was indeed a vacation time.
> > > >
> > > > This patch does not skip DM_USB_GADGET. What it does is declare
> > > > the UCLASS_DRIVER for USB peripheral devices even if
> > > > DM_USB_GADGET is not set.
> > > >
> > > > DM_USB_GADGET is a new option and not (yet) widely used and some
> > > > drivers have their own version of the DM support for gadget
> > > > drivers (ie they implement their own version of
> > > > usb_gadget_initialize(), usb_gadget_release() and
> > > > usb_gadget_handle_interrupts()). However all those drivers use
> > > > the UCLASS_USB_GADGET_GENERIC uclass ID and thus the
> > > > UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be declared.
> > > > In the past they used UCLASS_USB_DEV_GENERIC, but this option
> > > > is intended for the host side.  
> > >
> > > Acked-by: Jagan Teki 
> > >
> > > Marek, any comments?  
> >
> > Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
> > which also includes some other fixes.  
> 
> Please don't miss this, sunxi need this fix.

I'm now running build tests on this and Sam's patches. I will prepare
PR and send it to Marek or Tom (if Marek is overloaded).


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


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

Re: [U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now[Please note, mail behalf by 3vnmnxammciszqnjoyvtpbt.vynrlcly.fhunyvjr-jopwz....@chromium-sendgmr.bounces.google.com]

[Philipp Tomsich]

> On 03.01.2019, at 22:29, Simon Glass  wrote:
> 
> Hi,
> 
> On Thu, 3 Jan 2019 at 00:32, Kever Yang  > wrote:
>> 
>> Hi Simon,
>> 
>> 
>> On 12/29/2018 09:16 PM, Simon Glass wrote:
>>> This function causes a 5-second delay and stops the display working on
>>> minnie.
>> 
>> I don't understand why need 5-second, the logic is to check the adc key
>> press to decide the mode, maybe because the different usage of the adc
>> in minnie?
>> 
>> Most of boards(which do not have ec like chromebook) need this check to
>> get into download mode.
>> I would prefer chrombook to implement a function to replace the week
>> rockchip_dnl_mode_check();
> 
> But where is it specified in the DT that it uses the ADC for this
> feature? It really should have a driver…

3 things:
a.  It really should have a driver.
b.  One does not have to replace rockchip_dnl_mode_check(), as there
already is logic to remove it if CONFIG_ROCKCHIP_BOOT_MODE_REG
is set to 0 in the config.
c.  We really need to get away from configuring magic addresses via 
Kconfig. 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now[Please note, mail behalf by 3vnmnxammciszqnjoyvtpbt.vynrlcly.fhunyvjr-jopwz....@chromium-sendgmr.bounces.google.com]

[Simon Glass]

Hi,

On Thu, 3 Jan 2019 at 00:32, Kever Yang  wrote:
>
> Hi Simon,
>
>
> On 12/29/2018 09:16 PM, Simon Glass wrote:
> > This function causes a 5-second delay and stops the display working on
> > minnie.
>
> I don't understand why need 5-second, the logic is to check the adc key
> press to decide the mode, maybe because the different usage of the adc
> in minnie?
>
> Most of boards(which do not have ec like chromebook) need this check to
> get into download mode.
> I would prefer chrombook to implement a function to replace the week
> rockchip_dnl_mode_check();

But where is it specified in the DT that it uses the ADC for this
feature? It really should have a driver...

Regards,
Simon


>
> Thanks,
> - Kever
> > This code should be in a driver and should only be enabled by
> > a device-tree property, so that it does not affect devices which do not
> > have this feature.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  arch/arm/mach-rockchip/boot_mode.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/boot_mode.c 
> > b/arch/arm/mach-rockchip/boot_mode.c
> > index f32b3c4ce56..d7997d71e30 100644
> > --- a/arch/arm/mach-rockchip/boot_mode.c
> > +++ b/arch/arm/mach-rockchip/boot_mode.c
> > @@ -61,7 +61,13 @@ int setup_boot_mode(void)
> >   void *reg = (void *)CONFIG_ROCKCHIP_BOOT_MODE_REG;
> >   int boot_mode = readl(reg);
> >
> > - rockchip_dnl_mode_check();
> > + /*
> > +  * This should be handled using a driver-tree property and a suitable
> > +  * driver which can read the appropriate settings. As it is, this
> > +  * breaks chromebook_minnie.\
> > +  *
> > +  * rockchip_dnl_mode_check();
> > +  */
> >
> >   boot_mode = readl(reg);
> >   debug("%s: boot mode 0x%08x\n", __func__, boot_mode);
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Fix string property comparison overflow

[Simon Glass]

Hi Teddy,

On Fri, 23 Nov 2018 at 19:18, Teddy Reed  wrote:
>
> FDT property searching can overflow when comparing strings. This will
> result in undefined behavior. This upstream patch adds checks to assure
> property name lengths do not overrun the string region or the totalsize.
>
> The implementation is from upstream dtc:
>
> 70166d62a27f libfdt: Safer access to strings section
>
> Cc: Peter Robinson 
> Cc: David Gibson 
> Signed-off-by: Teddy Reed 
> ---
> Note this file is not synchronized from upstream dtc when using
> the scripts/dtc/update-dtc-source.sh script.
>
> The file size of the ELF increases with sandbox_spl_defconfig.
>
> $ bloaty spl/u-boot-spl -- spl/u-boot-spl.bin.before
>  VM SIZE  FILE SIZE
>  ----
>   [ = ]   0 .debug_loc+948  +0.3%
>   [ = ]   0 .debug_info   +284  +0.0%
>   +0.5%+176 .text +176  +0.5%
>   [ = ]   0 .debug_line   +150  +0.2%
>   [ = ]   0 .debug_ranges  +48  +0.2%
>   +0.4% +40 .eh_frame  +40  +0.4%
>   [ = ]   0 .debug_str +20  +0.0%
>   [ = ]   0 .debug_aranges +16  +0.1%
>+59% +16 [LOAD [RX]]+16   +59%
>   [ = ]   0 .strtab +4  +0.0%
>   [ = ]   0 [Unmapped]-238 -18.1%
>   +0.3%+232 TOTAL  +1.43Ki  +0.1%
>
> $ du -b spl/u-boot-spl.bin spl/u-boot-spl.bin.before
> 2174032 spl/u-boot-spl.bin
> 2174032 spl/u-boot-spl.bin.before
>
> You could also apply the patch:
>
> @@ -42,6 +42,11 @@ const char *fdt_string(const void *fdt, int stroffset)
>  static int _fdt_string_eq(const void *fdt, int stroffset,
>   const char *s, int len)
>  {
> +   int total_off = fdt_off_dt_strings(fdt) + stroffset;
> +   if (total_off + len + 1 < total_off ||
> +   total_off + len + 1 > fdt_totalsize(fdt))
> +   return 0;
> +
> const char *p = fdt_string(fdt, stroffset);
>
> return (strnlen(p, len + 1) == len) && (memcmp(p, s, len) == 0);
>
> To mitigate the read overflow, with minimum added bytes. I proposed this
> along with another change [1]. This was not a good idea since the change
> to scripts/dtc/libfdt/fdt.c is part of dtc synchronized from upsteam.
>
> [1] https://lists.denx.de/pipermail/u-boot/2018-June/330488.html
>
>  lib/libfdt/fdt_ro.c | 61 ++---
>  1 file changed, 58 insertions(+), 3 deletions(-)

Assuming this is for U-Boot then please cc me, as I don't often look
on the mailing list for patches.

I am worried about the code-size impact of this patch. It will likely
break quite a number of boards in SPL.

David already added some checks in libfdt upstream which I have not
synced to U-Boot for the same reason. We need some sort of build
option to exclude them for when space is tight. I have been thinking
of sending some patches upstream for this, but have not got to this
yet.

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

Re: [U-Boot] [PATCH] power: regulator: Return success on attempt to disable an always-on regulator

[Simon Glass]

Hi Lokesh,

On Sun, 30 Dec 2018 at 23:26, Lokesh Vutla  wrote:
>
> Hi Simon,
>
> On 29/12/18 6:58 PM, Simon Glass wrote:
> > Hi Lokesh,
> >
> > On Thu, 27 Dec 2018 at 22:33, Lokesh Vutla  wrote:
> >>
> >> Hi Simon,
> >>
> >> On 28/12/18 3:57 AM, Simon Glass wrote:
> >>> Hi Lokesh,
> >>>
> >>> On Mon, 24 Dec 2018 at 04:08, Lokesh Vutla  wrote:
> 
>  commit 4f86a724e82c0 ("power: regulator: denied disable on always-on
>  regulator") throws an error when requested to disable an always-on
>  regulator. It is right that an always-on regulator should not be
>  attempted to be disabled. But at the same time regulator framework
>  should not return an error when such request is received. Instead
>  it should just return success without attempting to disable the
>  specified regulator. This is because the requesting driver will
>  not have the idea if the regulator is always-on or not. The
>  requesting driver will always try to enable/disable regulator as
>  per the required flow. So it is upto regulator framework to not
>  break such scenarios.
> >>>
> >>> Can the caller not check the error code? It is -EACCES in this case.
> >>
> >> We considered this an one of the option but I ended up fixing regulator
> >> framework due to the following reasons:
> >> - If regulator framework returns -EACCES on this scenario then:
> >>  - -EACCES should be checked in all the existing usage of the 
> >> api[1] or else
> >> someone else might encounter the same problem.
> >
> > Yes. Some already check for -ENOSYS, e.g. omap_hsmmc.c
> >
> >>  - Any future usage of the api should take of handling this error.
> >
> > Yes, and it should be commented too.
> >
> >>  - From a client driver perspective it is not really an error. It 
> >> is doing the
> >> right thing and receiving an error might be confusing.
> >
> > The error means that the request was not handled. There is no way to
> > find out that requesting this was actually wrong.
> >
> >>
> >> Hope this is clear. Also just to add one more point, I adapted this error
> >> handling from Linux kernel[2].
> >
> > The only question for me whether anything would need to detect that
> > the request to disable a regulator is not supported.
> >
> > Your linux link appears to lead me to regulator_ena_gpio_ctrl(),
> > related to regulator GPIOs. Is that right? It's hard for me to
> > understand what the code there is doing.
>
> Looks like functions are moving around too fast. I am referring to the 
> function
> _regulator_disable() in the same file[1]. So logic of _regulator_disable() 
> looks
> something like below:
>
> _regulator_disable()
> {
> if (use_count == 1 && !always_on_regulator)
> .
> ret = _regulator_do_disable()
> .
> use_count = 0;
> else
> use_count--;
>
> return ret;
> }
>
> Obviously there are more things happening in the function but I just mentioned
> the details what we require.
>
> >
> > Once we make this change we will not be able to go back without breaking 
> > things.
> >
> > I am not really convinced that this patch is the best approach. I do
> > understand your point though. It just worries me that we are hiding
> > something and it will be hard to unhide it later.
> >
> > What do you think about adding something like
> > regulator_disable_if_allowed() which silently ignored -ENOSYS and
> > -EACCES?
>
> hmm...not sure if this is necessary. But if you feel "detecting the request to
> disable is not supported" might be needed in future, I can make something
> regulator_set_enable_if_allowed() and discard -ENOSYS and -EACCESS as you 
> suggested.

I think that would be useful. Another concern I have is that errors
that are suppressed at a low level can result in people checking for
success in other ways (e.g. reading data back in a separate
transaction). I think it is better to explicitly ignore specific error
numbers at the level where a decision can be made as to its
importance.

If I say 'please do this' I think it should mean 'return an error if
you cannot'. With driver model there are quite a few places where
errors are returned which might be harmless. For example.
gpio_request_by_name() returns -ENOENT if there is no GPIO by that
name, but returns -EINVAL if the config is invalid. We may want to
ignore the first one (e.g. if the GPIO is optional) but should never
ignore the second.

So a function like 'please do this if allowed' makes sense to me in
this context.

>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/core.c#n2627
>
> Thanks and regards,
> Lokesh

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

Re: [U-Boot] Issue faced due to "serial: Remove DM_FLAG_PRE_RELOC flag in various drivers" patch

[Simon Glass]

Hi Priyanka,

On Thu, 3 Jan 2019 at 03:31, Priyanka Jain  wrote:

> Hello,
>
> I am working to add support for NXP LX2160ARDB board support" "
> https://patchwork.ozlabs.org/patch/1004541/;
>
> For serial driver, we are using PL01X_SERIAL driver with DM_SERIAL enabled
> Since we need to support various clock frequencies, we have defined
> pl01x_serial_platdata in board file
> So it's a combination of CONFIG_DM_SERIAL + pl01x_serial_platdata
>
> Also we have requirement to use serial driver before relocation as well.
>
> Now with the patch  " serial: Remove DM_FLAG_PRE_RELOC flag in various
> drivers"
> the flag "DM_FLAG_PRE_RELOC" is no longer getting set resulting in UART
> driver not being available before relocation.
>
> I tried adding "u-boot,dm-pre-reloc" in uart node, but it doesn't helped.
> [May be because uart nodes are set to disable to use
> 'pl01x_serial_platdata' method]
>
> Can you please provide some suggestions on this issue.
> How to use "DM_SERIAL + pl01x_serial_platdata" feature in pre_reloc phase?
>

This really should be using device tree - how come your board cannot use
that?

But it seems that removing the flag has in fact made it impossible to use
platdata before relocation? That seems bad. One option is to create your
own driver when that flag set.

Regards,
Simon


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

[U-Boot] [PATCH 2/2] cmd: mmc: Invalidate MMC block cache after init

[Marek Vasut]

Make sure the block cache is cleared for the MMC device after it was
reinitialized to avoid having any stale data in the cache, like e.g.
partition tables or such.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
---
 cmd/mmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index ca8f982f53..9951315f91 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -108,6 +108,12 @@ static struct mmc *init_mmc_device(int dev, bool 
force_init)
mmc->has_init = 0;
if (mmc_init(mmc))
return NULL;
+
+#ifdef CONFIG_BLOCK_CACHE
+   struct blk_desc *bd = mmc_get_blk_desc(mmc);
+   blkcache_invalidate(bd->if_type, bd->devnum);
+#endif
+
return mmc;
 }
 static int do_mmcinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
-- 
2.19.2

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

[U-Boot] [PATCH 1/2] cmd: mmc: Force mmc reinit when no card present

[Marek Vasut]

In case the card is removed, force-init the MMC to start the internal
machinery which deregisters and invalidate the MMC device.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
---
 cmd/mmc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index 3920a1836a..ca8f982f53 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -101,6 +101,9 @@ static struct mmc *init_mmc_device(int dev, bool force_init)
return NULL;
}
 
+   if (!mmc_getcd(mmc))
+   force_init = true;
+
if (force_init)
mmc->has_init = 0;
if (mmc_init(mmc))
-- 
2.19.2

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

Re: [U-Boot] [PULL] Please pull u-boot-rockchip fixes for 2019.1

[Tom Rini]

On Thu, Jan 03, 2019 at 12:33:18PM +0100, Philipp Tomsich wrote:

> Tom,
> 
> Some additional fixes (Christoph’s series has been in-flight for a couple of 
> weeks
> due to my insistence on having pinctrl/regulators autoconfigured) for 2019.1.
> 
> The Travis-CI report is at 
> https://travis-ci.org/ptomsich/u-boot-rockchip/builds/474593290
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit f97c49d6a2f504d0f0a8aab37c67aa314e006250:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-01-01 
> 19:55:05 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git tags/for-master-20190103
> 
> for you to fetch changes up to 77012e79ffc35994e5d6efca458d65bd03842b00:
> 
>   rockchip: rk3399-puma: Set VDD_LOG to 950 mV. (2019-01-02 22:40:02 +0100)
> 

Applied to u-boot/master, 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] Pull request: u-boot-spi/master

[Tom Rini]

On Thu, Jan 03, 2019 at 12:49:12AM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this spi PR as part of 2019.01
> 
> thanks,
> Jagan.
> 
> The following changes since commit 08337cd64832ed7f8147da75013510b92bbcd188:
> 
>   riscv: bootm: Support booting VxWorks (2018-12-31 08:08:51 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 689795242b1cb7de5a3d8c8bf1a9582a8924ff69:
> 
>   dm: MIGRATION: Update migration plan for DM_SPI_FLASH (2019-01-02 01:00:31 
> +0530)
> 

Applied to u-boot/master, 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] Kconfig: don't pollute Kconfig w/ i.MX8M options for everyone

[Tom Rini]

On Thu, Jan 03, 2019 at 06:47:40PM +0100, Philipp Tomsich wrote:

> No point in showing the various DRAM options (right in the top-level
> menu for 'Device Drivers') for i.MX8M when configured for a different
> architecture.  This wraps an 'if ARCH_IMX8M' around these.
> 
> Signed-off-by: Philipp Tomsich 
> ---
> 
>  drivers/ddr/imx/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/ddr/imx/Kconfig b/drivers/ddr/imx/Kconfig
> index 7e06fb2..09a35e5 100644
> --- a/drivers/ddr/imx/Kconfig
> +++ b/drivers/ddr/imx/Kconfig
> @@ -1 +1,3 @@
> +if ARCH_IMX8M
>  source "drivers/ddr/imx/imx8m/Kconfig"
> +endif

Ugh.  We need drivers/ddr/imx/imx8m/Kconfig to have real 'depends on'
lines like all of the other DDR controllers.

-- 
Tom


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

[U-Boot] [PATCH] mmc: Add support for downgrading HS200/HS400 to HS mode

[Marek Vasut]

The mmc_select_mode_and_width() function can be called while the card
is in HS200/HS400 mode and can be used to downgrade the card to lower
mode, e.g. HS. This is used for example by mmc_boot_part_access_chk()
which cannot access the card in HS200/HS400 mode and which is in turn
called by saveenv if env is in the MMC.

In such case, forcing the card clock to legacy frequency cannot work.
Instead, the card must be switched to HS mode first, from which it can
then be reprogrammed as needed.

However, this procedure needs additional code changes, since the current
implementation checks whether the card correctly switched to HS mode in
mmc_set_card_speed(). The check only expects that the card will be going
to HS mode from lower modes, not from higher modes, hence add a parameter
which indicates that the HS200/HS400 to HS downgrade is happening. This
makes the code send the switch command first, reconfigure the controller
next and finally perform the EXT_CSD readback check. The last two steps
cannot be done in reverse order as the card is already in HS mode when
the clock are being switched on the controller side.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
---
 drivers/mmc/mmc.c | 39 +--
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f5c821e308..4899483b71 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -754,7 +754,8 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
 }
 
 #if !CONFIG_IS_ENABLED(MMC_TINY)
-static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode)
+static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
+ bool hsdowngrade)
 {
int err;
int speed_bits;
@@ -788,6 +789,20 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
bus_mode mode)
if (err)
return err;
 
+#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   /*
+* In case the eMMC is in HS200/HS400 mode and we are downgrading
+* to HS mode, the card clock are still running much faster than
+* the supported HS mode clock, so we can not reliably read out
+* Extended CSD. Reconfigure the controller to run at HS mode.
+*/
+   if (hsdowngrade) {
+   mmc_select_mode(mmc, MMC_HS);
+   mmc_set_clock(mmc, mmc_mode2freq(mmc, MMC_HS), false);
+   }
+#endif
+
if ((mode == MMC_HS) || (mode == MMC_HS_52)) {
/* Now check to see that it worked */
err = mmc_send_ext_csd(mmc, test_csd);
@@ -1849,7 +1864,7 @@ static int mmc_select_hs400(struct mmc *mmc)
int err;
 
/* Set timing to HS200 for tuning */
-   err = mmc_set_card_speed(mmc, MMC_HS_200);
+   err = mmc_set_card_speed(mmc, MMC_HS_200, false);
if (err)
return err;
 
@@ -1865,7 +1880,7 @@ static int mmc_select_hs400(struct mmc *mmc)
}
 
/* Set back to HS */
-   mmc_set_card_speed(mmc, MMC_HS);
+   mmc_set_card_speed(mmc, MMC_HS, false);
mmc_set_clock(mmc, mmc_mode2freq(mmc, MMC_HS), false);
 
err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BUS_WIDTH,
@@ -1873,7 +1888,7 @@ static int mmc_select_hs400(struct mmc *mmc)
if (err)
return err;
 
-   err = mmc_set_card_speed(mmc, MMC_HS_400);
+   err = mmc_set_card_speed(mmc, MMC_HS_400, false);
if (err)
return err;
 
@@ -1920,7 +1935,19 @@ static int mmc_select_mode_and_width(struct mmc *mmc, 
uint card_caps)
return -ENOTSUPP;
}
 
-   mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
+#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \
+CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   /*
+* In case the eMMC is in HS200/HS400 mode, downgrade to HS mode
+* before doing anything else, since a transition from either of
+* the HS200/HS400 mode directly to legacy mode is not supported.
+*/
+   if (mmc->selected_mode == MMC_HS_200 ||
+   mmc->selected_mode == MMC_HS_400)
+   mmc_set_card_speed(mmc, MMC_HS, true);
+   else
+#endif
+   mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
 
for_each_mmc_mode_by_pref(card_caps, mwt) {
for_each_supported_width(card_caps & mwt->widths,
@@ -1952,7 +1979,7 @@ static int mmc_select_mode_and_width(struct mmc *mmc, 
uint card_caps)
}
} else {
/* configure the bus speed (card) */
-   err = mmc_set_card_speed(mmc, mwt->mode);
+   err = mmc_set_card_speed(mmc, mwt->mode, false);
if (err)
goto error;
 
-- 
2.19.2

___
U-Boot mailing list

Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms

[Marek Vasut]

On 1/3/19 7:59 AM, Lukasz Majewski wrote:
> Hi Jagan,
> 
>> On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot 
>> wrote:
>>>
>>>
>>> On 29/12/2018 19:49, Jagan Teki wrote:  
 On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
  wrote:  
> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
>  wrote: Better to have proper commit head that
> tells the real issue.  
>>>
>>> I found it hard to come up with a short description of the real
>>> issue.
>>>
>>> At least this title makes it clear that it is a regression fix, not
>>> a new feature.
>>>
>>> The details of the failures  are in the commit log (or so I thought)
>>>  
>  
>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
>> USB gadget devices")
>>
>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
>> declared even for platforms that do not enable DM_USB_GADGET.
>> Otherwise the driver for their usb peripheral controller fails
>> to bind.  
> Sorry this is unclear, you are trying to skip DM_USB_GADGET code
> even though UCLASS_USB_GADGET_GENERIC id used. does it make
> sense?  
>>>
>>> Sorry for the delay. This was indeed a vacation time.
>>>
>>> This patch does not skip DM_USB_GADGET. What it does is declare the
>>> UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is
>>> not set.
>>>
>>> DM_USB_GADGET is a new option and not (yet) widely used and some
>>> drivers have their own version of the DM support for gadget drivers
>>> (ie they implement their own version of usb_gadget_initialize(),
>>> usb_gadget_release() and usb_gadget_handle_interrupts()). However
>>> all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and
>>> thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be
>>> declared. In the past they used UCLASS_USB_DEV_GENERIC, but this
>>> option is intended for the host side.  
>>
>> Acked-by: Jagan Teki 
>>
>> Marek, any comments?
> 
> Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
> which also includes some other fixes.

Comment on what ? What do you need from me here ?

This is gadget code, which is not something I monitor closely.

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

Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms

[Marek Vasut]

On 1/3/19 8:53 PM, Jagan Teki wrote:
> On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski  wrote:
>>
>> Hi Jagan,
>>
>>> On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot 
>>> wrote:


 On 29/12/2018 19:49, Jagan Teki wrote:
> On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
>  wrote:
>> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
>>  wrote: Better to have proper commit head that
>> tells the real issue.

 I found it hard to come up with a short description of the real
 issue.

 At least this title makes it clear that it is a regression fix, not
 a new feature.

 The details of the failures  are in the commit log (or so I thought)

>>
>>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
>>> USB gadget devices")
>>>
>>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
>>> declared even for platforms that do not enable DM_USB_GADGET.
>>> Otherwise the driver for their usb peripheral controller fails
>>> to bind.
>> Sorry this is unclear, you are trying to skip DM_USB_GADGET code
>> even though UCLASS_USB_GADGET_GENERIC id used. does it make
>> sense?

 Sorry for the delay. This was indeed a vacation time.

 This patch does not skip DM_USB_GADGET. What it does is declare the
 UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is
 not set.

 DM_USB_GADGET is a new option and not (yet) widely used and some
 drivers have their own version of the DM support for gadget drivers
 (ie they implement their own version of usb_gadget_initialize(),
 usb_gadget_release() and usb_gadget_handle_interrupts()). However
 all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and
 thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be
 declared. In the past they used UCLASS_USB_DEV_GENERIC, but this
 option is intended for the host side.
>>>
>>> Acked-by: Jagan Teki 
>>>
>>> Marek, any comments?
>>
>> Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
>> which also includes some other fixes.
> 
> Please don't miss this, sunxi need this fix.

Absolutely, I have nothing else to do but to monitor this one single
patch. Thanks for the pressure, it really helps.

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Jagan Teki]

On Thu, Jan 3, 2019 at 12:49 AM Jagan Teki  wrote:
>
> Hi Tom,
>
> Please pull this spi PR as part of 2019.01

This PR is for the release as well, please pick.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dm: usb: gadget: Fix boot breakage on sunxi platforms

[Jagan Teki]

On Thu, Jan 3, 2019 at 12:29 PM Lukasz Majewski  wrote:
>
> Hi Jagan,
>
> > On Wed, Jan 2, 2019 at 4:08 PM Jean-Jacques Hiblot 
> > wrote:
> > >
> > >
> > > On 29/12/2018 19:49, Jagan Teki wrote:
> > > > On Mon, Dec 24, 2018 at 3:44 AM Jagan Teki
> > > >  wrote:
> > > >> On Fri, Dec 21, 2018 at 2:20 PM Jean-Jacques Hiblot
> > > >>  wrote: Better to have proper commit head that
> > > >> tells the real issue.
> > >
> > > I found it hard to come up with a short description of the real
> > > issue.
> > >
> > > At least this title makes it clear that it is a regression fix, not
> > > a new feature.
> > >
> > > The details of the failures  are in the commit log (or so I thought)
> > >
> > > >>
> > > >>> Fixes commit 013116243950 ("dm: usb: create a new UCLASS ID for
> > > >>> USB gadget devices")
> > > >>>
> > > >>> The UCLASS_DRIVER for id UCLASS_USB_GADGET_GENERIC needs to be
> > > >>> declared even for platforms that do not enable DM_USB_GADGET.
> > > >>> Otherwise the driver for their usb peripheral controller fails
> > > >>> to bind.
> > > >> Sorry this is unclear, you are trying to skip DM_USB_GADGET code
> > > >> even though UCLASS_USB_GADGET_GENERIC id used. does it make
> > > >> sense?
> > >
> > > Sorry for the delay. This was indeed a vacation time.
> > >
> > > This patch does not skip DM_USB_GADGET. What it does is declare the
> > > UCLASS_DRIVER for USB peripheral devices even if DM_USB_GADGET is
> > > not set.
> > >
> > > DM_USB_GADGET is a new option and not (yet) widely used and some
> > > drivers have their own version of the DM support for gadget drivers
> > > (ie they implement their own version of usb_gadget_initialize(),
> > > usb_gadget_release() and usb_gadget_handle_interrupts()). However
> > > all those drivers use the UCLASS_USB_GADGET_GENERIC uclass ID and
> > > thus the UCLASS_DRIVER for UCLASS_USB_GADGET_GENERIC must be
> > > declared. In the past they used UCLASS_USB_DEV_GENERIC, but this
> > > option is intended for the host side.
> >
> > Acked-by: Jagan Teki 
> >
> > Marek, any comments?
>
> Yes, lets wait for Marek's comment and I will prepare PR (to Marek),
> which also includes some other fixes.

Please don't miss this, sunxi need this fix.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Please pull u-boot-video

[Anatolij Gustschin]

Hi Tom,

please pull some video updates for v2019.01.

Thanks,
Anatolij

The following changes since commit bea3d826203f90507ff32ed24bd0a3c53479e55c:

  Merge tag 'signed-efi-2019.01' of git://github.com/agraf/u-boot (2018-12-27 
12:59:01 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-video.git tags/for-v2019.01

for you to fetch changes up to daaba089f9dd3eee779a995abccc7e9c12a4d8bf:

  dm: video: fix test failures with enabled default TrueType font (2018-12-29 
11:28:59 +0100)


TrueType fixes and documentation


Anatolij Gustschin (1):
  dm: video: fix test failures with enabled default TrueType font

Simon Glass (3):
  video: Add information about using TrueType fonts
  video: Add a default TrueType font
  video: rockchip: Use TrueType fonts with jerry

 configs/chromebook_jerry_defconfig |  3 ++-
 doc/README.video   | 20 
 drivers/video/fonts/Kconfig|  1 +
 test/dm/video.c|  6 +++---
 4 files changed, 26 insertions(+), 4 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] lib: fdtdec: fdtdec_get_addr_size_fixed remove checks

[sjg]

On Fri, 21 Dec 2018 at 09:24, Keerthy  wrote:
>
> With 8 bytes addressing even on 32 bit machines these checks
> are no longer valid. Remove them.
>
> Signed-off-by: Keerthy 
> ---
>  lib/fdtdec.c | 10 --
>  1 file changed, 10 deletions(-)

Reviewed-by: Simon Glass 

Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] lib: fdtdec: fixup fdtdec_get_addr_size

[sjg]

On 12/21/18 9:24 AM, Keerthy wrote:
> fix up fdtdec_get_addr_size to use fdtdec_get_addr_size_auto_noparent
> so that the address cells and size cells are obtained from the
> parent instead of going by the fixed length.

This patch makes perfect sense to me. However, I am worried about the
potential existence of code that assumes the current fixed-size logic;
in the past when fixing similar issues like this we've often run into
code that was use "get addr" functions when it should have been using
"get u32" functions and similar, which then broke when we fixed the
implementation to do the right thing. I guess we should still apply the
patch, and fix up any fallout as it appears.

Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 4/8] arm: board: Remove board files for bubblegum_96

[André Przywara]

On 03/01/2019 13:26, Amit Singh Tomar wrote:
> Bubblegum board now gets driven from common owl framework, so
> let's remove the respected board files.

I think this patch could be split and merged into other patches, mostly 1/8.

> Signed-off-by: Amit Singh Tomar 
> ---
>  board/ucRobotics/bubblegum_96/Kconfig| 15 
>  board/ucRobotics/bubblegum_96/MAINTAINERS|  6 ---
>  board/ucRobotics/bubblegum_96/Makefile   |  3 --
>  board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 
> 
>  4 files changed, 80 deletions(-)
>  delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig
>  delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
>  delete mode 100644 board/ucRobotics/bubblegum_96/Makefile
>  delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
> 
> diff --git a/board/ucRobotics/bubblegum_96/Kconfig 
> b/board/ucRobotics/bubblegum_96/Kconfig
> deleted file mode 100644
> index 2dd40d9..000
> --- a/board/ucRobotics/bubblegum_96/Kconfig
> +++ /dev/null

That should be part of patch 1/8, where you remove the inclusion of that
file.

> @@ -1,15 +0,0 @@
> -if TARGET_BUBBLEGUM_96
> -
> -config SYS_BOARD
> - default "bubblegum_96"
> -
> -config SYS_VENDOR
> - default "ucRobotics"
> -
> -config SYS_SOC
> - default "s900"
> -
> -config SYS_CONFIG_NAME
> - default "bubblegum_96"
> -
> -endif
> diff --git a/board/ucRobotics/bubblegum_96/MAINTAINERS 
> b/board/ucRobotics/bubblegum_96/MAINTAINERS
> deleted file mode 100644
> index d0cb727..000
> --- a/board/ucRobotics/bubblegum_96/MAINTAINERS
> +++ /dev/null

Can you please adjust the paths in /MAINTAINERS? board/ucRobotics will
be gone after this patch, that should be reflected there.
This could be the only thing left in this patch or merged into 1/8.

> @@ -1,6 +0,0 @@
> -BUBBLEGUM_96 BOARD
> -M:   Manivannan Sadhasivam 
> -S:   Maintained
> -F:   board/ucRobotics/bubblegum_96/
> -F:   include/configs/bubblegum_96.h
> -F:   configs/bubblegum_96_defconfig
> diff --git a/board/ucRobotics/bubblegum_96/Makefile 
> b/board/ucRobotics/bubblegum_96/Makefile
> deleted file mode 100644
> index c4b524d..000
> --- a/board/ucRobotics/bubblegum_96/Makefile
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -# SPDX-License-Identifier:   GPL-2.0+
> -
> -obj-y   := bubblegum_96.o
> diff --git a/board/ucRobotics/bubblegum_96/bubblegum_96.c 
> b/board/ucRobotics/bubblegum_96/bubblegum_96.c
> deleted file mode 100644
> index a4c202d..000
> --- a/board/ucRobotics/bubblegum_96/bubblegum_96.c
> +++ /dev/null

That should be part of 1/8 as well, where you more or less rename that
file here. That helps git to detect this and show this accordingly.

Cheers,
Andre.

> @@ -1,56 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Bubblegum-96 Boards Support
> - *
> - * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -/*
> - * dram_init - sets uboots idea of sdram size
> - */
> -int dram_init(void)
> -{
> - gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
> - return 0;
> -}
> -
> -/* This is called after dram_init() so use get_ram_size result */
> -int dram_init_banksize(void)
> -{
> - gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> - gd->bd->bi_dram[0].size = gd->ram_size;
> -
> - return 0;
> -}
> -
> -static void show_psci_version(void)
> -{
> - struct arm_smccc_res res;
> -
> - arm_smccc_smc(ARM_PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0, 0, 0, 0, 0, );
> -
> - printf("PSCI:  v%ld.%ld\n",
> -PSCI_VERSION_MAJOR(res.a0),
> - PSCI_VERSION_MINOR(res.a0));
> -}
> -
> -int board_init(void)
> -{
> - show_psci_version();
> -
> - return 0;
> -}
> -
> -void reset_cpu(ulong addr)
> -{
> - psci_system_reset();
> -}
> 

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

Re: [U-Boot] [PATCH] dm: video: fix test failures with enabled default TrueType font

[Anatolij Gustschin]

On Sat, 29 Dec 2018 01:09:19 +0100
Anatolij Gustschin ag...@denx.de wrote:

> With enabled default Nimbus font dm_test_video_truetype* tests fail.
> Update expected expressions to fix them.
> 
> Signed-off-by: Anatolij Gustschin 
> ---
>  test/dm/video.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH] buildman: Deal nicely with invalid build-status file

[sjg]

The 'done' files created by buildman may end up being empty if buildman
runs out of disk space while writing them. This error is then persistent,
since even if disk space is reclaimed and the build retries, the empty
file causes an exception in the builder thread.

Deal with this silently by doing a rebuild.

Signed-off-by: Simon Glass 
---

 tools/buildman/builderthread.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Applied to u-boot-dm/master, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] sandbox: Correct SDL build flags

[sjg]

The check for CONFIG_SANDBOX_SDL in config.mk does not work since the
build config is not available by the time that file is included. Remove it
so that we always call sdl-config except when NO_SDL is used.

Signed-off-by: Simon Glass 
---

 arch/sandbox/config.mk | 2 --
 arch/sandbox/cpu/sdl.c | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

Applied to u-boot-dm/master, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Kconfig: don't pollute Kconfig w/ i.MX8M options for everyone

[Philipp Tomsich]

No point in showing the various DRAM options (right in the top-level
menu for 'Device Drivers') for i.MX8M when configured for a different
architecture.  This wraps an 'if ARCH_IMX8M' around these.

Signed-off-by: Philipp Tomsich 
---

 drivers/ddr/imx/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ddr/imx/Kconfig b/drivers/ddr/imx/Kconfig
index 7e06fb2..09a35e5 100644
--- a/drivers/ddr/imx/Kconfig
+++ b/drivers/ddr/imx/Kconfig
@@ -1 +1,3 @@
+if ARCH_IMX8M
 source "drivers/ddr/imx/imx8m/Kconfig"
+endif
-- 
2.1.4

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

Re: [U-Boot] [RFC PATCH 1/8] arm: actions: Add common framework for Actions Semi SoCs

[André Przywara]

On 03/01/2019 13:26, Amit Singh Tomar wrote:
> This adds common arch owl support that drives both s700
> and s900, 64-bits SoCs from Actions Semiconductor.

Nice cleanup.

> 
> Signed-off-by: Amit Singh Tomar 
> ---
>  arch/arm/Kconfig   |  2 --
>  arch/arm/mach-owl/Kconfig  | 31 +++
>  arch/arm/mach-owl/Makefile |  2 +-
>  arch/arm/mach-owl/soc.c| 56 
> ++
>  configs/bubblegum_96_defconfig |  3 +--
>  include/configs/bubblegum_96.h | 42 ---
>  include/configs/owl-common.h   | 42 +++
>  include/configs/s700.h | 15 +++
>  include/configs/s900.h | 18 ++
>  9 files changed, 147 insertions(+), 64 deletions(-)
>  create mode 100644 arch/arm/mach-owl/soc.c
>  delete mode 100644 include/configs/bubblegum_96.h
>  create mode 100644 include/configs/owl-common.h
>  create mode 100644 include/configs/s700.h
>  create mode 100644 include/configs/s900.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5952ad..b478096 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -760,7 +760,6 @@ config ARCH_MX5
>  
>  config ARCH_OWL
>   bool "Actions Semi OWL SoCs"
> - select ARM64
>   select DM
>   select DM_SERIAL
>   select OF_CONTROL
> @@ -1555,7 +1554,6 @@ source "board/spear/spear600/Kconfig"
>  source "board/spear/x600/Kconfig"
>  source "board/st/stv0991/Kconfig"
>  source "board/tcl/sl50/Kconfig"
> -source "board/ucRobotics/bubblegum_96/Kconfig"
>  source "board/birdland/bav335x/Kconfig"
>  source "board/toradex/colibri_pxa270/Kconfig"
>  source "board/vscom/baltos/Kconfig"
> diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
> index 199e772..3143782 100644
> --- a/arch/arm/mach-owl/Kconfig
> +++ b/arch/arm/mach-owl/Kconfig
> @@ -1,27 +1,24 @@
>  if ARCH_OWL
>  
> -config SYS_SOC
> - default "owl"
> -
>  choice
> -prompt "Actions Semi OWL SoCs board select"
> +prompt "SemiActions SoC Variant"

Even after refactoring the company is still called Actions Semi ;-)

>  optional
>  
> -config TARGET_BUBBLEGUM_96
> - bool "96Boards Bubblegum-96"
> - help
> -   Support for 96Boards Bubblegum-96. This board complies with
> -   96Board Consumer Edition Specification. Features:
> -   - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
> -   - 2GiB RAM
> -   - 8GiB eMMC, uSD slot
> -   - WiFi, Bluetooth and GPS module
> -   - 2x Host, 1x Device USB port
> -   - HDMI
> -   - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
> +config MACH_S700
> +bool "SemiActions S700"
> +select ARM64

It's probably a bit premature to introduce S700 here already. Just move
that to a later patch.

> +
> +config MACH_S900
> +bool "SemiActions S900"
> +select ARM64
>  
>  endchoice
>  
> -source "board/ucRobotics/bubblegum_96/Kconfig"
> +config SYS_CONFIG_NAME
> +default "s900" if MACH_S900
> +default "s700" if MACH_S700

Same here.

> +
> +config SYS_SOC
> +default "owl"
>  
>  endif
> diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
> index 1b43dc2..2a76ee0 100644
> --- a/arch/arm/mach-owl/Makefile
> +++ b/arch/arm/mach-owl/Makefile
> @@ -1,3 +1,3 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  
> -obj-y += sysmap-s900.o

That breaks Bubblegum compilation. Just keep it in for now and remove it
in the next patch.

> +obj-y += soc.o
> diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c
> new file mode 100644
> index 000..a4c202d
> --- /dev/null
> +++ b/arch/arm/mach-owl/soc.c
> @@ -0,0 +1,56 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bubblegum-96 Boards Support

That line should be changed to reflect the new generic nature of that file.

> + *
> + * Copyright (C) 2018 Manivannan Sadhasivam 
> 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * dram_init - sets uboots idea of sdram size
> + */
> +int dram_init(void)
> +{
> + gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
> + return 0;
> +}
> +
> +/* This is called after dram_init() so use get_ram_size result */
> +int dram_init_banksize(void)
> +{
> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> +
> + return 0;
> +}
> +
> +static void show_psci_version(void)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(ARM_PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0, 0, 0, 0, 0, );
> +
> + printf("PSCI:  v%ld.%ld\n",
> +PSCI_VERSION_MAJOR(res.a0),
> + PSCI_VERSION_MINOR(res.a0));

looks like a whitespace issue

> +}
> +
> +int board_init(void)
> +{
> + show_psci_version();
> +
> + return 0;
> +}
> +
> +void reset_cpu(ulong addr)
> +{
> + psci_system_reset();
> +}
> diff --git 

Re: [U-Boot] Booting on RK3399

[Jagan Teki]

On Thu, Jan 3, 2019 at 9:10 PM Mark Kettenis  wrote:
>
> > From: Jagan Teki 
> > Date: Thu, 3 Jan 2019 20:53:43 +0530
> >
> > On Thu, Jan 3, 2019 at 7:20 AM Mark Kettenis  
> > wrote:
> > >
> > > > From: Simon Glass 
> > > > Date: Wed, 2 Jan 2019 18:15:31 -0700
> > > >
> > > > Hi Kever,
> > > >
> > > > I have a firefly-rk3399 and would like to boot it into U-Boot (as a 
> > > > start)
> > > > from an uSD card.
> > > >
> > > > Are there instructions somewhere on how to do this? I gather that I need
> > > > OP-TEE but not how to build it or how to put the image together. I would
> > > > like to have instructions in README.rockchip if possible.
> > > >
> > > > I'm planning to add U-Boot support for bob and maybe kevin (both
> > > > Chromebooks) but am not sure where to start. I thought the firefly 
> > > > might be
> > > > best since it is pretty common.
> > >
> > > Hi Simon,
> > >
> > > The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
> > > the firefly-rk3399 as well.  I've successfully built working firmware
> > > for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
> > > past that way.
> >
> > What is TF-A here, I'm trying to build master, but it's failed to build
>
> TF-A (Trusted Firmware-A) == ATF (Arm Trusted Firmware)
>
> For seam reasom ARM, eh I mean arm, decided to rebrand it.
>
>
> > $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
> > make -C plat/rockchip/rk3399/drivers/m0
> > BUILD=/root/arm-trusted-firmware/build/rk3399/release/m0
> > make[1]: Entering directory
> > '/root/arm-trusted-firmware/plat/rockchip/rk3399/drivers/m0'
> >   CC  src/dram.c
> > arm-none-eabi-gcc -g -mcpu=cortex-m0 -mthumb -Wall -O3 -nostdlib
> > -mfloat-abi=soft -ffunction-sections -fdata-sections
> > -fomit-frame-pointer -fno-common -Iinclude/ -I../../include/shared/
> > -MMD -MT /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o -c
> > src/dram.c -o /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o
> > make[1]: arm-none-eabi-gcc: Command not found
>
> The RK3399 has a Cortex-M0 MCU built into it, and TF-A includes a
> firmware for that.  I think it is supposed to assist the SoC with
> suspend/resume.
>
> You'll need to install an arm-none-eabi- cross compiler as well to
> build it.

Thanks.

Burn the images on SD as below, but the board boot from eMMC.  So it
will boot from SD only eMMC has bad image or any jumper to make SD
boot?
$ ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
$ sudo dd if=idbspl.img of=/dev/sda seek=64
$ sudo dd if=u-boot.itb of=/dev/sda seek=16384
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC

[Stefan Agner]

[this time using reply to all]

On 03.01.19 03:36, Adam Ford wrote:
> The LogicPD board uses a Micron Flash with ECC.  To boot this from
> SPL, the ECC needs to be correctly configured or the BCH engine
> times out.
> 
> Signed-off-by: Adam Ford 

Looks good to me,

Acked-by: Stefan Agner 

> 
> diff --git a/drivers/mtd/nand/raw/mxs_nand.c b/drivers/mtd/nand/raw/mxs_nand.c
> index e3341812a2..2d84bfffe2 100644
> --- a/drivers/mtd/nand/raw/mxs_nand.c
> +++ b/drivers/mtd/nand/raw/mxs_nand.c
> @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand)
>  
>   nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
>   nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
> +
> + if (is_mx6sx() || is_mx7())
> + nand_info->max_ecc_strength_supported = 62;
> + else
> + nand_info->max_ecc_strength_supported = 40;
> +
>   err = mxs_nand_alloc_buffers(nand_info);
>   if (err)
>   return err;
> diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c 
> b/drivers/mtd/nand/raw/mxs_nand_spl.c
> index c628f3adec..ba85baac60 100644
> --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> @@ -201,6 +201,7 @@ static int mxs_nand_init(void)
>   /* setup flash layout (does not scan as we override that) */
>   mtd->size = nand_chip.chipsize;
>   nand_chip.scan_bbt(mtd);
> + mxs_nand_setup_ecc(mtd);
>  
>   return 0;
>  }
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: bcm6368: fix restart flow issues

[Daniel Schwierzeck]

Am 01.01.19 um 19:44 schrieb Álvaro Fernández Rojas:
> Correctly enable/disable bcm6368-net controller to avoid flow issues.
> 
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  drivers/net/bcm6368-eth.c | 109 
> ++
>  1 file changed, 62 insertions(+), 47 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] drivers: block: Allow to cache 4K blocks by default

[Tom Rini]

On Thu, Jan 03, 2019 at 04:42:08PM +0100, Jan Kiszka wrote:
> On 20.12.18 09:45, Marek Vasut wrote:
> >On 12/10/2018 01:28 PM, Tom Rini wrote:
> >>On Mon, Dec 10, 2018 at 05:13:58AM +0100, Marek Vasut wrote:
> >>>On 12/09/2018 09:55 AM, Jan Kiszka wrote:
> The default settings of the block cache so far only allow to hold single
> 1K blocks. However, larger filesystems tend to use 4K. Failing to cache
> those massively degrades access performance unless you manually tune the
> cache first. This is not desirable.
> 
> Signed-off-by: Jan Kiszka 
> >>>
> >>>I submitted the same patch before [1], oddly enough it was not picked by
> >>>Tom.
> >>>
> >>>[1]
> >>>http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.html
> >>
> >>Based on a quick re-read, I had filed that patch as "Marek says he'll
> >>look into a more complex but general scheme".  If that's not the case
> >>then yes, we can just do that.  Thanks!
> >
> >I still don't see the original patch in u-boot/master
> >
> 
> Ping. Some form of this change should go into the next release, IMHO.

So, this initially tripped over some EFI related issue, which has been
fixed.  But at this point I'm going to pull it in from v2019.04 instead.

-- 
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] MTD: nand: mxs_nand_spl: Fix empty function pointer for BBT

[Stefan Agner]

On 30.12.18 17:11, Adam Ford wrote:
> The initialization function calls a nand_chip.scan_bbt(mtd) but
> scan_bbt is never initialized resulting in an undefined function
> pointer.  This will direct the function pointer to nand_default_bbt
> defined in the same file.
>
> Signed-off-by: Adam Ford 

Seems sensible

Acked-by: Stefan Agner 


>
> diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c 
> b/drivers/mtd/nand/raw/mxs_nand_spl.c
> index 2d7bbe83cc..c628f3adec 100644
> --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> @@ -185,6 +185,7 @@ static int mxs_nand_init(void)
>   mtd = nand_to_mtd(_chip);
>   /* set mtd functions */
>   nand_chip.cmdfunc = mxs_nand_command;
> + nand_chip.scan_bbt = nand_default_bbt;
>   nand_chip.numchips = 1;
>  
>   /* identify flash device */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] bmips: fix config warnings from 2019.01

[Daniel Schwierzeck]

Am 02.01.19 um 23:14 schrieb Tom Rini:
> On Wed, Jan 02, 2019 at 11:11:09PM +0100, Álvaro Fernández Rojas wrote:
> 
>> Hi Marek,
>>
>> Check commits 841d5fbae4e993476fa87d8933db0cd58d3c2d41 and
>> 109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7.
>>
>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=841d5fbae4e993476fa87d8933db0cd58d3c2d41
>>
>>
>> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7
> 
> Right.  But Marek is asking for something more like:
> - Use of CONFIG_OF_EMBED isn't intended for deployment use, switch to
>   CONFIG_OF_SEPARATE instead.
> - We can fully migrate to CONIG_DM_USB so enable CONFIG_BLK now.
> 
> ie why we're changing things, not just that we're fixing the warning.
> 

two patches would be good. In each one you could add a "Fixes:
841d5fbae4e993476fa87d8933db0cd58d3c2d41" or "Fixes:
109d8bf3ac7b9bb04f3c46bb540eb2bb865f3dd7".

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

Re: [U-Boot] Booting on RK3399

[Philipp Tomsich]

> On 03.01.2019, at 16:40, Mark Kettenis  wrote:
> 
>> From: Jagan Teki 
>> Date: Thu, 3 Jan 2019 20:53:43 +0530
>> 
>> On Thu, Jan 3, 2019 at 7:20 AM Mark Kettenis  wrote:
>>> 
 From: Simon Glass 
 Date: Wed, 2 Jan 2019 18:15:31 -0700
 
 Hi Kever,
 
 I have a firefly-rk3399 and would like to boot it into U-Boot (as a start)
 from an uSD card.
 
 Are there instructions somewhere on how to do this? I gather that I need
 OP-TEE but not how to build it or how to put the image together. I would
 like to have instructions in README.rockchip if possible.
 
 I'm planning to add U-Boot support for bob and maybe kevin (both
 Chromebooks) but am not sure where to start. I thought the firefly might be
 best since it is pretty common.
>>> 
>>> Hi Simon,
>>> 
>>> The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
>>> the firefly-rk3399 as well.  I've successfully built working firmware
>>> for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
>>> past that way.
>> 
>> What is TF-A here, I'm trying to build master, but it's failed to build
> 
> TF-A (Trusted Firmware-A) == ATF (Arm Trusted Firmware)
> 
> For seam reasom ARM, eh I mean arm, decided to rebrand it.
> 
> 
>> $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
>> make -C plat/rockchip/rk3399/drivers/m0
>> BUILD=/root/arm-trusted-firmware/build/rk3399/release/m0
>> make[1]: Entering directory
>> '/root/arm-trusted-firmware/plat/rockchip/rk3399/drivers/m0'
>>  CC  src/dram.c
>> arm-none-eabi-gcc -g -mcpu=cortex-m0 -mthumb -Wall -O3 -nostdlib
>> -mfloat-abi=soft -ffunction-sections -fdata-sections
>> -fomit-frame-pointer -fno-common -Iinclude/ -I../../include/shared/
>> -MMD -MT /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o -c
>> src/dram.c -o /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o
>> make[1]: arm-none-eabi-gcc: Command not found
> 
> The RK3399 has a Cortex-M0 MCU built into it, and TF-A includes a
> firmware for that.  I think it is supposed to assist the SoC with
> suspend/resume.

In fact there’s two M0s: one in the PMU power domain and the other in
the PERI power domain. The ATF uses the one in the PMU domain for
suspend/resume and during DFS on DRAM.

I am working (it’s not my highest priority, though) on getting these booted
before entering ATF from SPL, so the PMU M0 is no longer being started
from ATF but actually running on ATF entry.

> You'll need to install an arm-none-eabi- cross compiler as well to
> build it.
> 
> Cheers,
> 
> Mark
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de 
> https://lists.denx.de/listinfo/u-boot 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/2] dm: usb: udc: Use SEQ_ALIAS to index the USB gadget ports

[Sam Protsenko]

Tested on BeagleBoard X15, works fine. Thanks, Jean-Jacques!

Lukasz, is there any way this series can make it to v2019.01 release?
Like to see it there, for stability/consistence reasons.

Reviewed-by: Sam Protsenko 
Tested-by: Sam Protsenko 

Thanks!

On Sun, Dec 16, 2018 at 10:47 PM Lukasz Majewski  wrote:
>
> Hi Marek, Jean-Jacques,
>
> > On 12/15/2018 05:43 PM, Jean-Jacques Hiblot wrote:
> > > dfu, fastbot and other usb gadget commands take the USB port index
> > > as a
> >
> > fastboot.
> >
> > Looks good to me, I expect Lukasz to pick it, test it and send me a
> > PR.
> >
> > > parameter. Currently this index is assigned in the order of the
> > > driver bindings.
> > > Changing this behavior using the SEQ_ALIAS feature. This option
> > > assign to the device a SEQ number based on its alias (if it exists)
> > >
> > > To use it we must set the DM_UC_FLAG_SEQ_ALIAS flag and follow the
> > > existing naming convention: use "usb" for the name of the gadget
> > > UCLASS_DRIVER (same as for the UCLASS_USB).
>
> I must admit that this change fixes a long standing problem with the
> usb number assignment.
>
> Great job. I will test and send it in a few days time.
>
> > >
> > > If no alias is provided, then the index falls back to the order in
> > > which the bindings took place.
> > >
> > > Signed-off-by: Jean-Jacques Hiblot 
> > > Reported-by: Sam Protsenko 
> > > ---
> > >
> > >  drivers/usb/gadget/udc/udc-uclass.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/usb/gadget/udc/udc-uclass.c
> > > b/drivers/usb/gadget/udc/udc-uclass.c index 0620518..e9f8f5f 100644
> > > --- a/drivers/usb/gadget/udc/udc-uclass.c
> > > +++ b/drivers/usb/gadget/udc/udc-uclass.c
> > > @@ -20,7 +20,7 @@ int usb_gadget_initialize(int index)
> > > return -EINVAL;
> > > if (dev_array[index])
> > > return 0;
> > > -   ret = uclass_get_device(UCLASS_USB_GADGET_GENERIC, index,
> > > );
> > > +   ret = uclass_get_device_by_seq(UCLASS_USB_GADGET_GENERIC,
> > > index, ); if (!dev || ret) {
> > > pr_err("No USB device found\n");
> > > return -ENODEV;
> > > @@ -54,5 +54,6 @@ int usb_gadget_handle_interrupts(int index)
> > >
> > >  UCLASS_DRIVER(usb_gadget_generic) = {
> > > .id = UCLASS_USB_GADGET_GENERIC,
> > > -   .name   = "usb_gadget_generic",
> > > +   .name   = "usb",
> > > +   .flags  = DM_UC_FLAG_SEQ_ALIAS,
> > >  };
> > >
> >
> >
>
>
>
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: block: Allow to cache 4K blocks by default

[Jan Kiszka]

On 20.12.18 09:45, Marek Vasut wrote:

On 12/10/2018 01:28 PM, Tom Rini wrote:

On Mon, Dec 10, 2018 at 05:13:58AM +0100, Marek Vasut wrote:

On 12/09/2018 09:55 AM, Jan Kiszka wrote:

The default settings of the block cache so far only allow to hold single
1K blocks. However, larger filesystems tend to use 4K. Failing to cache
those massively degrades access performance unless you manually tune the
cache first. This is not desirable.

Signed-off-by: Jan Kiszka 


I submitted the same patch before [1], oddly enough it was not picked by
Tom.

[1]
http://u-boot.10912.n7.nabble.com/PATCH-RFC-blk-Increase-cache-element-size-td337975.html


Based on a quick re-read, I had filed that patch as "Marek says he'll
look into a more complex but general scheme".  If that's not the case
then yes, we can just do that.  Thanks!


I still don't see the original patch in u-boot/master



Ping. Some form of this change should go into the next release, IMHO.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Booting on RK3399

[Mark Kettenis]

> From: Jagan Teki 
> Date: Thu, 3 Jan 2019 20:53:43 +0530
> 
> On Thu, Jan 3, 2019 at 7:20 AM Mark Kettenis  wrote:
> >
> > > From: Simon Glass 
> > > Date: Wed, 2 Jan 2019 18:15:31 -0700
> > >
> > > Hi Kever,
> > >
> > > I have a firefly-rk3399 and would like to boot it into U-Boot (as a start)
> > > from an uSD card.
> > >
> > > Are there instructions somewhere on how to do this? I gather that I need
> > > OP-TEE but not how to build it or how to put the image together. I would
> > > like to have instructions in README.rockchip if possible.
> > >
> > > I'm planning to add U-Boot support for bob and maybe kevin (both
> > > Chromebooks) but am not sure where to start. I thought the firefly might 
> > > be
> > > best since it is pretty common.
> >
> > Hi Simon,
> >
> > The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
> > the firefly-rk3399 as well.  I've successfully built working firmware
> > for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
> > past that way.
> 
> What is TF-A here, I'm trying to build master, but it's failed to build

TF-A (Trusted Firmware-A) == ATF (Arm Trusted Firmware)

For seam reasom ARM, eh I mean arm, decided to rebrand it.


> $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
> make -C plat/rockchip/rk3399/drivers/m0
> BUILD=/root/arm-trusted-firmware/build/rk3399/release/m0
> make[1]: Entering directory
> '/root/arm-trusted-firmware/plat/rockchip/rk3399/drivers/m0'
>   CC  src/dram.c
> arm-none-eabi-gcc -g -mcpu=cortex-m0 -mthumb -Wall -O3 -nostdlib
> -mfloat-abi=soft -ffunction-sections -fdata-sections
> -fomit-frame-pointer -fno-common -Iinclude/ -I../../include/shared/
> -MMD -MT /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o -c
> src/dram.c -o /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o
> make[1]: arm-none-eabi-gcc: Command not found

The RK3399 has a Cortex-M0 MCU built into it, and TF-A includes a
firmware for that.  I think it is supposed to assist the SoC with
suspend/resume.

You'll need to install an arm-none-eabi- cross compiler as well to
build it.

Cheers,

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

Re: [U-Boot] [PATCH v3 0/6] mips: mscc: gpio: Add MSCC serial GPIO driver

[Daniel Schwierzeck]

Am 02.01.19 um 09:52 schrieb Lars Povlsen:
> This patch series add the GPIO device (SIO) in the MSCC VCoreIII-based
> SOCs, and enables it on the supported platforms.
> 
> By using a serial interface, the SIO controller significantly extends
> the number of available GPIOs with a minimum number of additional pins
> on the device. The primary purpose of the SIO controller is to connect
> control signals from SFP modules and to act as an LED controller.
> 
> This version address comments from Daniel Schwierzeck
>  and Linus Walleij
> .
> 
> This is based off the u-boot-mips repository.
> 
> v3 changes:
>  - Fail driver load if clk_get_rate() fails
>  - Use dev_remap_addr() instead of map_physmem()
>  - Use dev_err instead of printf
>  - (DT doc) ngpios: Refer to gpio.txt
> 
> v2 changes:
>  - Extended the DT bindings documentation
>  - Eliminated the need for the "mscc,sgpio-bitcount" property.
>  - Using dev_read_u32_default() instead of fdtdec_get_int()
>  - Using map_physmem()
>  - Added MAINTAINERS entry for driver
> 
> Lars Povlsen (6):
>   mips: mscc_sgpio: Add the MSCC serial GPIO device (SIO)
>   mips: mscc_sgpio: Add DT bindings documentation
>   mips: luton: DT: Enable use of serial gpio
>   mips: luton: Enable use of serial gpio for LED
>   mips: ocelot: DT: Enable use of serial gpio
>   mips: ocelot: Enable use of serial gpio for LED
> 
>  MAINTAINERS  |   1 +
>  arch/mips/dts/luton_pcb090.dts   |  21 ++
>  arch/mips/dts/luton_pcb091.dts   |  27 ++
>  arch/mips/dts/mscc,luton.dtsi|  20 ++
>  arch/mips/dts/mscc,ocelot.dtsi   |  23 ++
>  arch/mips/dts/ocelot_pcb120.dts  |  76 +
>  arch/mips/dts/ocelot_pcb123.dts  |  25 ++
>  board/mscc/luton/luton.c |   6 +
>  board/mscc/ocelot/ocelot.c   |   6 +
>  configs/mscc_luton_defconfig |   3 +
>  configs/mscc_ocelot_defconfig|   3 +
>  doc/device-tree-bindings/gpio/mscc_sgpio.txt |  45 +++
>  drivers/gpio/Kconfig |  11 +
>  drivers/gpio/Makefile|   1 +
>  drivers/gpio/mscc_sgpio.c| 275 +++
>  15 files changed, 543 insertions(+)
>  create mode 100644 doc/device-tree-bindings/gpio/mscc_sgpio.txt
>  create mode 100644 drivers/gpio/mscc_sgpio.c
> 

series applied to u-boot-mips/next, thanks.

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

Re: [U-Boot] Booting on RK3399

[Jagan Teki]

On Thu, Jan 3, 2019 at 7:20 AM Mark Kettenis  wrote:
>
> > From: Simon Glass 
> > Date: Wed, 2 Jan 2019 18:15:31 -0700
> >
> > Hi Kever,
> >
> > I have a firefly-rk3399 and would like to boot it into U-Boot (as a start)
> > from an uSD card.
> >
> > Are there instructions somewhere on how to do this? I gather that I need
> > OP-TEE but not how to build it or how to put the image together. I would
> > like to have instructions in README.rockchip if possible.
> >
> > I'm planning to add U-Boot support for bob and maybe kevin (both
> > Chromebooks) but am not sure where to start. I thought the firefly might be
> > best since it is pretty common.
>
> Hi Simon,
>
> The instructions in board/u-boot/rockchip/evb_rk3399/README apply to
> the firefly-rk3399 as well.  I've successfully built working firmware
> for my board using the TF-A (ATF) 2.0 release and U-Boot SPL in the
> past that way.

What is TF-A here, I'm trying to build master, but it's failed to build

$ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31
make -C plat/rockchip/rk3399/drivers/m0
BUILD=/root/arm-trusted-firmware/build/rk3399/release/m0
make[1]: Entering directory
'/root/arm-trusted-firmware/plat/rockchip/rk3399/drivers/m0'
  CC  src/dram.c
arm-none-eabi-gcc -g -mcpu=cortex-m0 -mthumb -Wall -O3 -nostdlib
-mfloat-abi=soft -ffunction-sections -fdata-sections
-fomit-frame-pointer -fno-common -Iinclude/ -I../../include/shared/
-MMD -MT /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o -c
src/dram.c -o /root/arm-trusted-firmware/build/rk3399/release/m0/dram.o
make[1]: arm-none-eabi-gcc: Command not found
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] tools/imx8m_image.sh: remove bashism

[Christopher Spencer]

On Wed, 2 Jan 2019 at 07:00, Baruch Siach  wrote:
> Use a single '=' to test string equality for compatibility with non-bash
> shells. Otherwise, if /bin/sh is dash, build fails:
> 
> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
> ./tools/imx8m_image.sh: 15: [: spl/u-boot-spl-ddr.bin: unexpected operator
> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is 
> not-functional
> 
> Signed-off-by: Baruch Siach 

Tested-by: Chris Spencer 

Thanks,
Chris

Disclaimer: 

This email has been scanned for all known viruses by the MessageLabs Email 
Security System.

The contents of this email (including any attachments) are intended for the use 
of the mail addressee(s) shown, hence is private and in addition may include 
commercially sensitive information. If you are not the intended recipient of 
this email any disclosure, copying, distribution or use of its contents is 
strictly prohibited. You should notify the sender immediately and then delete 
it (including any attachments) from your system.

The information contained in or attached to this message may also be subject to 
the export control laws and regulations of the United Kingdom and the United 
States. This specifically includes, but is not limited to, the Arms Export 
Control Act (22 U.S.C. 2751-2794) and the International Traffic in Arms 
Regulation (22 C.F.R 120-130) as well as the Export Administration Act (50 
U.S.C. App. 2401-2420), the Export Administration Regulation (15 C.F.R. 
730-774) and the UK Export Control Act 2002.

Please help out the environment by only printing this e-mail if absolutely 
necessary - Thank you. 

SEA is the brand name of Systems Engineering & Assessment Ltd (registered 
office: Beckington Castle, 17 Castle Corner, Beckington, Frome, Somerset, BA11 
6TA, UK - company number 02302168).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform

[Tom Rini]

On Thu, Jan 03, 2019 at 09:00:41AM +0100, Michal Simek wrote:
> On 26. 12. 18 15:29, Tom Rini wrote:
> > On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
> >> Hi Michal,
> >>
> >> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek  
> >> wrote:
> >>>
> >>> On 20. 12. 18 9:09, Bin Meng wrote:
>  On Thu, Dec 20, 2018 at 3:55 PM Michal Simek  
>  wrote:
> >
> > Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
> >
> > Signed-off-by: Michal Simek 
> > ---
> >
> > Patch needs to be applied when this PR is merged.
> > https://github.com/swarren/uboot-test-hooks/pull/21
> >
> > ---
> >  .travis.yml | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index 6e4b4ba0a34a..e14e6987e4cf 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -454,6 +454,14 @@ matrix:
> >QEMU_TARGET="arm-softmmu"
> >TEST_PY_ID="--id qemu"
> >BUILDMAN="^zynq_zc702$"
> > +- name: "test/py xilinx_versal_virt"
> > +  env:
> > +- TEST_PY_BD="xilinx_versal_virt"
> > +  TEST_PY_TEST_SPEC="not sleep"
> > +  QEMU_TARGET="aarch64-softmmu"
> > +  QEMU_VERSION="v3.1.0"
> > +  TEST_PY_ID="--id qemu"
> > +  BUILDMAN="^xilinx_versal_virt$"
> 
>  Can we turn on 3.1.0 for all QEMU targets?
> >>>
> >>> I expected this question.
> >>> First of all I wanted to enable an option to be able to wire whatever
> >>> version. Even sha1 for not released version.
> >>>
> >>> I think we can try to test v3.1.0 qemu version for all boards but I will
> >>> let Tom to decide is we can move or not.
> >>>
> >>
> >> Yes, please try to test that. If everything is good, I see no reason
> >> not using it.
> > 
> > Yes, I would also like to move everyone up to v3.1.0 and also having the
> > version we use be spelled out will help with future reproducibility.
> > 
> 
> v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
> take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
> I am happy to keep them on v3.0 and move the rest to v3.1 and let
> vexpress guys to figured out what's wrong with v3.1 and configs around.
> 
> What do you think?

The error is:
 Captured stdout setup -
+u-boot-test-reset vexpress_ca15_tc2 qemu
qemu-system-arm: -tftp: invalid option

And I guess the problem is that by v3.1.0 -tftp has been removed and we
need to use -netdev user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} like on
the other QEMU-based targets.  Can you update uboot-test-hooks (change
.travis.yml to clone your fork of uboot-test-hooks rather than
swarren's) to have the modern syntax?  Thanks!

-- 
Tom


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

[U-Boot] [RFC PATCH 4/8] arm: board: Remove board files for bubblegum_96

[Amit Singh Tomar]

Bubblegum board now gets driven from common owl framework, so
let's remove the respected board files.

Signed-off-by: Amit Singh Tomar 
---
 board/ucRobotics/bubblegum_96/Kconfig| 15 
 board/ucRobotics/bubblegum_96/MAINTAINERS|  6 ---
 board/ucRobotics/bubblegum_96/Makefile   |  3 --
 board/ucRobotics/bubblegum_96/bubblegum_96.c | 56 
 4 files changed, 80 deletions(-)
 delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig
 delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
 delete mode 100644 board/ucRobotics/bubblegum_96/Makefile
 delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c

diff --git a/board/ucRobotics/bubblegum_96/Kconfig 
b/board/ucRobotics/bubblegum_96/Kconfig
deleted file mode 100644
index 2dd40d9..000
--- a/board/ucRobotics/bubblegum_96/Kconfig
+++ /dev/null
@@ -1,15 +0,0 @@
-if TARGET_BUBBLEGUM_96
-
-config SYS_BOARD
-   default "bubblegum_96"
-
-config SYS_VENDOR
-   default "ucRobotics"
-
-config SYS_SOC
-   default "s900"
-
-config SYS_CONFIG_NAME
-   default "bubblegum_96"
-
-endif
diff --git a/board/ucRobotics/bubblegum_96/MAINTAINERS 
b/board/ucRobotics/bubblegum_96/MAINTAINERS
deleted file mode 100644
index d0cb727..000
--- a/board/ucRobotics/bubblegum_96/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-BUBBLEGUM_96 BOARD
-M: Manivannan Sadhasivam 
-S: Maintained
-F: board/ucRobotics/bubblegum_96/
-F: include/configs/bubblegum_96.h
-F: configs/bubblegum_96_defconfig
diff --git a/board/ucRobotics/bubblegum_96/Makefile 
b/board/ucRobotics/bubblegum_96/Makefile
deleted file mode 100644
index c4b524d..000
--- a/board/ucRobotics/bubblegum_96/Makefile
+++ /dev/null
@@ -1,3 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-
-obj-y   := bubblegum_96.o
diff --git a/board/ucRobotics/bubblegum_96/bubblegum_96.c 
b/board/ucRobotics/bubblegum_96/bubblegum_96.c
deleted file mode 100644
index a4c202d..000
--- a/board/ucRobotics/bubblegum_96/bubblegum_96.c
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Bubblegum-96 Boards Support
- *
- * Copyright (C) 2018 Manivannan Sadhasivam 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-/*
- * dram_init - sets uboots idea of sdram size
- */
-int dram_init(void)
-{
-   gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
-   return 0;
-}
-
-/* This is called after dram_init() so use get_ram_size result */
-int dram_init_banksize(void)
-{
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-   gd->bd->bi_dram[0].size = gd->ram_size;
-
-   return 0;
-}
-
-static void show_psci_version(void)
-{
-   struct arm_smccc_res res;
-
-   arm_smccc_smc(ARM_PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0, 0, 0, 0, 0, );
-
-   printf("PSCI:  v%ld.%ld\n",
-  PSCI_VERSION_MAJOR(res.a0),
-   PSCI_VERSION_MINOR(res.a0));
-}
-
-int board_init(void)
-{
-   show_psci_version();
-
-   return 0;
-}
-
-void reset_cpu(ulong addr)
-{
-   psci_system_reset();
-}
-- 
2.7.4

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

[U-Boot] [RFC PATCH 6/8] arm: add Cubieboard7 board support

[Amit Singh Tomar]

The Cubieboard is a single board computer containing a
Actions S700 SoC(with 4 ARMv8 Cortex-A53 cores).

This patch adds respective defconfig alongwith device tree(sync with
Linux 4.20).

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/dts/s700-cubieboard7.dts | 39 +++
 configs/cubieboard7_defconfig | 22 ++
 2 files changed, 61 insertions(+)
 create mode 100644 arch/arm/dts/s700-cubieboard7.dts
 create mode 100644 configs/cubieboard7_defconfig

diff --git a/arch/arm/dts/s700-cubieboard7.dts 
b/arch/arm/dts/s700-cubieboard7.dts
new file mode 100644
index 000..28f3f4a
--- /dev/null
+++ b/arch/arm/dts/s700-cubieboard7.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include "s700.dtsi"
+
+/ {
+   compatible = "cubietech,cubieboard7", "actions,s700";
+   model = "CubieBoard7";
+
+   aliases {
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = "serial3:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+
+   memory@1,e000 {
+   device_type = "memory";
+   reg = <0x1 0xe000 0x0 0x0>;
+   };
+};
+
+ {
+   clocks = <>;
+};
+
+ {
+   status = "okay";
+};
diff --git a/configs/cubieboard7_defconfig b/configs/cubieboard7_defconfig
new file mode 100644
index 000..f870839
--- /dev/null
+++ b/configs/cubieboard7_defconfig
@@ -0,0 +1,22 @@
+CONFIG_ARM=y
+CONFIG_ARM_SMCCC=y
+CONFIG_ARCH_OWL=y
+CONFIG_SYS_TEXT_BASE=0x1100
+CONFIG_MACH_S700=y
+CONFIG_IDENT_STRING="\ncubieboard7"
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_BOOTDELAY=5
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyOWL3,115200n8"
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_SYS_PROMPT="U-Boot => "
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIMER=y
+CONFIG_DEFAULT_DEVICE_TREE="s700-cubieboard7"
+CONFIG_CLK=y
+CONFIG_CLK_OWL=y
+CONFIG_OWL_SERIAL=y
-- 
2.7.4

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

[U-Boot] [RFC PATCH 8/8] actions: add Cubieboard7 README

[Amit Singh Tomar]

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/mach-owl/README.cubieboard7 | 88 
 1 file changed, 88 insertions(+)
 create mode 100644 arch/arm/mach-owl/README.cubieboard7

diff --git a/arch/arm/mach-owl/README.cubieboard7 
b/arch/arm/mach-owl/README.cubieboard7
new file mode 100644
index 000..de0f3f7
--- /dev/null
+++ b/arch/arm/mach-owl/README.cubieboard7
@@ -0,0 +1,88 @@
+Default Cubieboard7 comes with pre-installed Android where U-Boot is 
configured with a bootdelay of 0, entering a prompt by pressing keys does not 
seem to work. 
+
+Though, one can enter ADFU mode and flash debian image(from host machine) 
where getting into u-boot prompt is easy.
+
+Enter ADFU Mode:
+
+Before write the firmware, let the development board entering the ADFU mode: 
insert
+one end of the USB cable to the PC, press and hold the ADFU button, and then 
connect
+the other end of the USB cable to the Mini USB port of the development board, 
release
+the ADFU button, after connecting it will enter the ADFU mode.
+
+Check whether to enter ADFU Mode:
+
+The user needs to run the following command on the PC side to check if the ADFU
+device is detected. ID realted to "Actions Semiconductor Co., Ltd"  means that 
+the PC side has been correctly detected ADFU device, the development board 
+also enter into the ADFU mode.
+ 
+#lsusb
+Bus 001 Device 005: ID 04f2:b2eb Chicony Electronics Co., Ltd 
+Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 
[ThinkPad]
+Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
+Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
+Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+Bus 003 Device 013: ID 10d6:10d6 Actions Semiconductor Co., Ltd 
+Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+
+Flashing debian image:
+
+#sudo ./ActionsFWU.py --fw=debian-stretch-desktop-cb7-emmc-v2.0.fw
+ActionsFWU.py  : 1.0.150828.0830
+libScript.so: 2.3.150825.0951
+libFileSystem.so: 2.3.150825.0952
+libProduction.so: 2.3.150915.1527
+=burn all partition
+FW_VER: 3.10.37.180608
+3% DOWNLOAD ADFUDEC ...
+5% DOWNLOAD BOOT PARA ...
+7% SWITCH ADFUDEC ...
+12% DOWNLOAD BL31 ...
+13% DOWNLOAD BL32 ...
+15% DOWNLOAD VMLINUX ...
+20% DOWNLOAD INITRD ...
+24% DOWNLOAD FDT ...
+27% DOWNLOAD ADFUS ...
+30% SWITCH ADFUS ...
+32% DOWNLOAD MBR ...
+35% DOWNLOAD PARTITIONS ...
+WRITE_MBRC_PARTITION
+35% write p0 size = 2048 : ok
+WRITE_BOOT_PARTITION
+35% write p1 size = 2048 : ok
+WRITE_MISC_PARTITION
+36% write p2 size = 98304 : ok
+WRITE_SYSTEM_PARTITION
+94% write p3 size = 4608000 : ok
+FORMAT_SWAP_PARTITION
+94% write p4 size = 20480 : ok
+95% TRANSFER OVER ...
+Firmware upgrade successfully!
+
+Debian image can be downloaded from here[1].
+
+Once debian image is flashed, one can get into u-boot prompt by pressing any 
key and from
+there run ums command(make sure, usb cable is connected between host and 
target):
+
+owl> ums 0 mmc 1
+
+Above command would mount debian image partition on host machine.
+
+Getting Cubieboard7 u-boot proper image:
+
+From u-boot root directory run following:
+
+#make clean
+#export CROSS_COMPILE=aarch64-linux-gnu-
+#make ARCH=arm cubieboard7_defconfig
+#make -j16
+#mkimage -A arm -T firmware -C none -O u-boot -a 0x1100 -e 0 -d 
u-boot-dtb.bin u-boot-dtb.img  >/dev/null
+
+u-boot-dtb.img can now be flashed to debian image partition mounted on host 
machine.
+
+#sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1024 seek=3072
+
+
+[1] https://mega.nz/#F!ZtwxCCJC!AIYHcTqz-ucjuzKnE9qD7A!xpJ0CSjQ
+
-- 
2.7.4

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

[U-Boot] [RFC PATCH 7/8] serial: actions: add uart support for s700

[Amit Singh Tomar]

UART controller present on S700 is compatible with existing
S900 UART, this patch simply adds a proper compatible string
so that S900 uart driver can be reused for S700.

Signed-off-by: Amit Singh Tomar 
---
 drivers/serial/serial_owl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/serial/serial_owl.c b/drivers/serial/serial_owl.c
index 7ead73e..76995bf 100644
--- a/drivers/serial/serial_owl.c
+++ b/drivers/serial/serial_owl.c
@@ -121,6 +121,7 @@ static const struct dm_serial_ops owl_serial_ops = {
 
 static const struct udevice_id owl_serial_ids[] = {
{ .compatible = "actions,s900-serial" },
+   { .compatible = "actions,owl-uart" },
{ }
 };
 
-- 
2.7.4

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

[U-Boot] [RFC PATCH 5/8] arm: actions: add S700 SoC device tree

[Amit Singh Tomar]

This patch adds .dtsi file(sync with Linux 4.20) and required binding
for S700 SoC that is a 64-bit Quad-core ARM Cortex-A53 cores.

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/dts/s700.dtsi   | 193 +++
 include/dt-bindings/clock/actions,s700-cmu.h | 118 
 2 files changed, 311 insertions(+)
 create mode 100644 arch/arm/dts/s700.dtsi
 create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h

diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
new file mode 100644
index 000..a74c75a
--- /dev/null
+++ b/arch/arm/dts/s700.dtsi
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Andreas Färber
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "actions,s700";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   };
+
+   cpu1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   };
+
+   cpu2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   };
+
+   cpu3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x3>;
+   enable-method = "psci";
+   };
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   secmon@1f00 {
+   reg = <0x0 0x1f00 0x0 0x100>;
+   no-map;
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   arm-pmu {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts = ,
+,
+,
+;
+   interrupt-affinity = <>, <>, <>, <>;
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   hosc: hosc {
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   #clock-cells = <0>;
+   };
+
+   losc: losc {
+   compatible = "fixed-clock";
+   clock-frequency = <32768>;
+   #clock-cells = <0>;
+   };
+
+   soc {
+   u-boot,dm-pre-reloc;
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   gic: interrupt-controller@e00f1000 {
+   compatible = "arm,gic-400";
+   reg = <0x0 0xe00f1000 0x0 0x1000>,
+ <0x0 0xe00f2000 0x0 0x2000>,
+ <0x0 0xe00f4000 0x0 0x2000>,
+ <0x0 0xe00f6000 0x0 0x2000>;
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   };
+
+   uart0: serial@e012 {
+   compatible = "actions,s900-uart", "actions,owl-uart";
+   reg = <0x0 0xe012 0x0 0x2000>;
+   clocks = < CLK_UART0>;
+   interrupts = ;
+   status = "disabled";
+   };
+
+   uart1: serial@e0122000 {
+   compatible = "actions,s900-uart", "actions,owl-uart";
+   reg = <0x0 0xe0122000 0x0 0x2000>;
+   clocks = < CLK_UART1>;
+   interrupts = ;
+   status = "disabled";
+   };
+
+   uart2: serial@e0124000 {
+   compatible = "actions,s900-uart", "actions,owl-uart";
+   reg = <0x0 0xe0124000 0x0 0x2000>;
+   clocks = < CLK_UART2>;
+   interrupts = ;
+   status = "disabled";
+   };
+
+   uart3: serial@e0126000 {
+   u-boot,dm-pre-reloc;
+   compatible = "actions,s900-uart", 

[U-Boot] [RFC PATCH 2/8] arm: actions: Add owl memory map regions

[Amit Singh Tomar]

This adds memory regions needed to setup MMU for actions
S900 and S700 SoCs.

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/mach-owl/Makefile  |  1 +
 arch/arm/mach-owl/sysmap-owl.c  | 32 
 arch/arm/mach-owl/sysmap-s900.c | 32 
 3 files changed, 33 insertions(+), 32 deletions(-)
 create mode 100644 arch/arm/mach-owl/sysmap-owl.c
 delete mode 100644 arch/arm/mach-owl/sysmap-s900.c

diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
index 2a76ee0..417c859 100644
--- a/arch/arm/mach-owl/Makefile
+++ b/arch/arm/mach-owl/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-y += soc.o
+obj-y += sysmap-owl.o
diff --git a/arch/arm/mach-owl/sysmap-owl.c b/arch/arm/mach-owl/sysmap-owl.c
new file mode 100644
index 000..9dc4a05
--- /dev/null
+++ b/arch/arm/mach-owl/sysmap-owl.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semi S900/S700 Memory map
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+#include 
+#include 
+
+static struct mm_region owl_mem_map[] = {
+   {
+   .virt = 0x0UL, /* DDR */
+   .phys = 0x0UL, /* DDR */
+   .size = 0x8000UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   }, {
+   .virt = 0xE000UL, /* Peripheral block */
+   .phys = 0xE000UL, /* Peripheral block */
+   .size = 0x0800UL,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+   }, {
+   /* List terminator */
+   0,
+   }
+};
+
+struct mm_region *mem_map = owl_mem_map;
diff --git a/arch/arm/mach-owl/sysmap-s900.c b/arch/arm/mach-owl/sysmap-s900.c
deleted file mode 100644
index f78b639..000
--- a/arch/arm/mach-owl/sysmap-s900.c
+++ /dev/null
@@ -1,32 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Actions Semi S900 Memory map
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam 
- */
-
-#include 
-#include 
-
-static struct mm_region s900_mem_map[] = {
-   {
-   .virt = 0x0UL, /* DDR */
-   .phys = 0x0UL, /* DDR */
-   .size = 0x8000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0xE000UL, /* Peripheral block */
-   .phys = 0xE000UL, /* Peripheral block */
-   .size = 0x0800UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   /* List terminator */
-   0,
-   }
-};
-
-struct mm_region *mem_map = s900_mem_map;
-- 
2.7.4

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

[U-Boot] [RFC PATCH 3/8] clk: actions: Add common clock driver

[Amit Singh Tomar]

CMU block on most of the actions SoC seems to be identical(S900,
S700 and S500)?

This patch converts S900 clock driver to something common that can
be used for other SoCs, for instance S700(most of clk registres are same).

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/include/asm/arch-owl/clk_owl.h   |  61 +
 arch/arm/include/asm/arch-owl/clk_s900.h  |  57 -
 arch/arm/include/asm/arch-owl/regs_s700.h |  56 
 drivers/clk/owl/Kconfig   |   8 +-
 drivers/clk/owl/Makefile  |   2 +-
 drivers/clk/owl/clk_owl.c | 132 
 drivers/clk/owl/clk_s900.c| 137 --
 7 files changed, 252 insertions(+), 201 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
 delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
 create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
 create mode 100644 drivers/clk/owl/clk_owl.c
 delete mode 100644 drivers/clk/owl/clk_s900.c

diff --git a/arch/arm/include/asm/arch-owl/clk_owl.h 
b/arch/arm/include/asm/arch-owl/clk_owl.h
new file mode 100644
index 000..8ff7537
--- /dev/null
+++ b/arch/arm/include/asm/arch-owl/clk_owl.h
@@ -0,0 +1,61 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Actions Semi S900 Clock Definitions
+ *
+ * Copyright (C) 2015 Actions Semi Co., Ltd.
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ *
+ */
+
+#ifndef _OWL_CLK_H_
+#define _OWL_CLK_H_
+
+#include 
+
+struct owl_clk_priv {
+   phys_addr_t base;
+};
+
+/* BUSCLK register definitions */
+#define CMU_PDBGDIV_8  7
+#define CMU_PDBGDIV_SHIFT  26
+#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
+#define CMU_PERDIV_8   7
+#define CMU_PERDIV_SHIFT   20
+#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
+#define CMU_NOCDIV_2   1
+#define CMU_NOCDIV_SHIFT   19
+#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
+#define CMU_DMMCLK_SRC_APLL2
+#define CMU_DMMCLK_SRC_SHIFT   10
+#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
+#define CMU_APBCLK_DIV BIT(8)
+#define CMU_NOCCLK_SRC BIT(7)
+#define CMU_AHBCLK_DIV BIT(4)
+#define CMU_CORECLK_MASK   3
+#define CMU_CORECLK_CPLL   BIT(1)
+#define CMU_CORECLK_HOSC   BIT(0)
+
+/* COREPLL register definitions */
+#define CMU_COREPLL_EN BIT(9)
+#define CMU_COREPLL_HOSC_ENBIT(8)
+#define CMU_COREPLL_OUT(1104 / 24)
+
+/* DEVPLL register definitions */
+#define CMU_DEVPLL_CLK BIT(12)
+#define CMU_DEVPLL_EN  BIT(8)
+#define CMU_DEVPLL_OUT (660 / 6)
+
+/* UARTCLK register definitions */
+#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
+
+/* DEVCLKEN1 register definitions */
+#if defined(CONFIG_MACH_S900)
+#define CMU_DEVCLKEN1_UART5BIT(21)
+#elif defined(CONFIG_MACH_S700)
+#define CMU_DEVCLKEN1_UART3 BIT(11)
+#endif
+
+#define PLL_STABILITY_WAIT_US  50
+
+#endif
diff --git a/arch/arm/include/asm/arch-owl/clk_s900.h 
b/arch/arm/include/asm/arch-owl/clk_s900.h
deleted file mode 100644
index 88e88f7..000
--- a/arch/arm/include/asm/arch-owl/clk_s900.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * Actions Semi S900 Clock Definitions
- *
- * Copyright (C) 2015 Actions Semi Co., Ltd.
- * Copyright (C) 2018 Manivannan Sadhasivam 
- *
- */
-
-#ifndef _OWL_CLK_S900_H_
-#define _OWL_CLK_S900_H_
-
-#include 
-
-struct owl_clk_priv {
-   phys_addr_t base;
-};
-
-/* BUSCLK register definitions */
-#define CMU_PDBGDIV_8  7
-#define CMU_PDBGDIV_SHIFT  26
-#define CMU_PDBGDIV_DIV(CMU_PDBGDIV_8 << CMU_PDBGDIV_SHIFT)
-#define CMU_PERDIV_8   7
-#define CMU_PERDIV_SHIFT   20
-#define CMU_PERDIV_DIV (CMU_PERDIV_8 << CMU_PERDIV_SHIFT)
-#define CMU_NOCDIV_2   1
-#define CMU_NOCDIV_SHIFT   19
-#define CMU_NOCDIV_DIV (CMU_NOCDIV_2 << CMU_NOCDIV_SHIFT)
-#define CMU_DMMCLK_SRC_APLL2
-#define CMU_DMMCLK_SRC_SHIFT   10
-#define CMU_DMMCLK_SRC (CMU_DMMCLK_SRC_APLL << CMU_DMMCLK_SRC_SHIFT)
-#define CMU_APBCLK_DIV BIT(8)
-#define CMU_NOCCLK_SRC BIT(7)
-#define CMU_AHBCLK_DIV BIT(4)
-#define CMU_CORECLK_MASK   3
-#define CMU_CORECLK_CPLL   BIT(1)
-#define CMU_CORECLK_HOSC   BIT(0)
-
-/* COREPLL register definitions */
-#define CMU_COREPLL_EN BIT(9)
-#define CMU_COREPLL_HOSC_ENBIT(8)
-#define CMU_COREPLL_OUT(1104 / 24)
-
-/* DEVPLL register definitions */
-#define CMU_DEVPLL_CLK BIT(12)
-#define CMU_DEVPLL_EN  BIT(8)
-#define CMU_DEVPLL_OUT (660 / 6)
-
-/* UARTCLK register definitions */
-#define CMU_UARTCLK_SRC_DEVPLL BIT(16)
-
-/* DEVCLKEN1 register definitions */
-#define CMU_DEVCLKEN1_UART5BIT(21)
-
-#define PLL_STABILITY_WAIT_US  50
-
-#endif
diff --git a/arch/arm/include/asm/arch-owl/regs_s700.h 

[U-Boot] [RFC PATCH 1/8] arm: actions: Add common framework for Actions Semi SoCs

[Amit Singh Tomar]

This adds common arch owl support that drives both s700
and s900, 64-bits SoCs from Actions Semiconductor.

Signed-off-by: Amit Singh Tomar 
---
 arch/arm/Kconfig   |  2 --
 arch/arm/mach-owl/Kconfig  | 31 +++
 arch/arm/mach-owl/Makefile |  2 +-
 arch/arm/mach-owl/soc.c| 56 ++
 configs/bubblegum_96_defconfig |  3 +--
 include/configs/bubblegum_96.h | 42 ---
 include/configs/owl-common.h   | 42 +++
 include/configs/s700.h | 15 +++
 include/configs/s900.h | 18 ++
 9 files changed, 147 insertions(+), 64 deletions(-)
 create mode 100644 arch/arm/mach-owl/soc.c
 delete mode 100644 include/configs/bubblegum_96.h
 create mode 100644 include/configs/owl-common.h
 create mode 100644 include/configs/s700.h
 create mode 100644 include/configs/s900.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5952ad..b478096 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -760,7 +760,6 @@ config ARCH_MX5
 
 config ARCH_OWL
bool "Actions Semi OWL SoCs"
-   select ARM64
select DM
select DM_SERIAL
select OF_CONTROL
@@ -1555,7 +1554,6 @@ source "board/spear/spear600/Kconfig"
 source "board/spear/x600/Kconfig"
 source "board/st/stv0991/Kconfig"
 source "board/tcl/sl50/Kconfig"
-source "board/ucRobotics/bubblegum_96/Kconfig"
 source "board/birdland/bav335x/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
 source "board/vscom/baltos/Kconfig"
diff --git a/arch/arm/mach-owl/Kconfig b/arch/arm/mach-owl/Kconfig
index 199e772..3143782 100644
--- a/arch/arm/mach-owl/Kconfig
+++ b/arch/arm/mach-owl/Kconfig
@@ -1,27 +1,24 @@
 if ARCH_OWL
 
-config SYS_SOC
-   default "owl"
-
 choice
-prompt "Actions Semi OWL SoCs board select"
+prompt "SemiActions SoC Variant"
 optional
 
-config TARGET_BUBBLEGUM_96
-   bool "96Boards Bubblegum-96"
-   help
- Support for 96Boards Bubblegum-96. This board complies with
- 96Board Consumer Edition Specification. Features:
- - Actions Semi S900 SoC (4xCortex A53, Power VR G6230 GPU)
- - 2GiB RAM
- - 8GiB eMMC, uSD slot
- - WiFi, Bluetooth and GPS module
- - 2x Host, 1x Device USB port
- - HDMI
- - 20-pin low speed and 40-pin high speed expanders, 6 LED, 3 buttons
+config MACH_S700
+bool "SemiActions S700"
+select ARM64
+
+config MACH_S900
+bool "SemiActions S900"
+select ARM64
 
 endchoice
 
-source "board/ucRobotics/bubblegum_96/Kconfig"
+config SYS_CONFIG_NAME
+default "s900" if MACH_S900
+default "s700" if MACH_S700
+
+config SYS_SOC
+default "owl"
 
 endif
diff --git a/arch/arm/mach-owl/Makefile b/arch/arm/mach-owl/Makefile
index 1b43dc2..2a76ee0 100644
--- a/arch/arm/mach-owl/Makefile
+++ b/arch/arm/mach-owl/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0+
 
-obj-y += sysmap-s900.o
+obj-y += soc.o
diff --git a/arch/arm/mach-owl/soc.c b/arch/arm/mach-owl/soc.c
new file mode 100644
index 000..a4c202d
--- /dev/null
+++ b/arch/arm/mach-owl/soc.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bubblegum-96 Boards Support
+ *
+ * Copyright (C) 2018 Manivannan Sadhasivam 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * dram_init - sets uboots idea of sdram size
+ */
+int dram_init(void)
+{
+   gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
+   return 0;
+}
+
+/* This is called after dram_init() so use get_ram_size result */
+int dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].size = gd->ram_size;
+
+   return 0;
+}
+
+static void show_psci_version(void)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(ARM_PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0, 0, 0, 0, 0, );
+
+   printf("PSCI:  v%ld.%ld\n",
+  PSCI_VERSION_MAJOR(res.a0),
+   PSCI_VERSION_MINOR(res.a0));
+}
+
+int board_init(void)
+{
+   show_psci_version();
+
+   return 0;
+}
+
+void reset_cpu(ulong addr)
+{
+   psci_system_reset();
+}
diff --git a/configs/bubblegum_96_defconfig b/configs/bubblegum_96_defconfig
index 4b00a17..6c31b1c 100644
--- a/configs/bubblegum_96_defconfig
+++ b/configs/bubblegum_96_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARM_SMCCC=y
 CONFIG_ARCH_OWL=y
 CONFIG_SYS_TEXT_BASE=0x1100
-CONFIG_TARGET_BUBBLEGUM_96=y
+CONFIG_MACH_S900=y
 CONFIG_IDENT_STRING="\nBubblegum-96"
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=1
@@ -19,5 +19,4 @@ CONFIG_CMD_TIMER=y
 CONFIG_DEFAULT_DEVICE_TREE="bubblegum_96"
 CONFIG_CLK=y
 CONFIG_CLK_OWL=y
-CONFIG_CLK_S900=y
 CONFIG_OWL_SERIAL=y
diff --git a/include/configs/bubblegum_96.h b/include/configs/bubblegum_96.h
deleted file mode 100644
index e1dc37b..000
--- a/include/configs/bubblegum_96.h

[U-Boot] [RFC PATCH 0/8] Actions S700 SoC support

[Amit Singh Tomar]

Hello,

This patch-set adds Cubieboard7[1] support based on Action Semi's S700 SoC[2], 
It's Quad-core ARMv8 SoC 
with Cortex-A53 cores.Most of peripherals seems to be compatible with S900 
SoC(basic support for it
is alreay present in u-boot).

First few patches consolidates Actions Semiconductor SoCs support in 
u-boot((mostly insprired by SUXNI
as suggested by Andre).Idea is to move every bit out from board/ucRobotics into 
arch/arm/mach-owl. It 
allows different SoCs to be driven by single "soc and Kconfig" file. It also 
includes common clock driver 
for S700 and S900.Rest of patches enables S700 SoC support alongwith 
Cubieboard7 board.

S700 support is tested[3] on Cubieboard7 board and S900 support is just 
compiled tested.It would
be great, if someone who has S900 based board can test S900 support.

Thanks,
-Amit

[1]: http://www.cubietech.com/product-detail/cubieboard7/
[2]: http://www.actions-semi.com/en/productview.aspx?id=225
[3]: https://paste.ubuntu.com/p/fkCdv5nw2Q/

Amit Singh Tomar (8):
  arm: actions: Add common framework for Actions Semi SoCs
  arm: actions: Add owl memory map regions
  clk: actions: Add common clock driver
  arm: board: Remove board files for bubblegum_96
  arm: actions: add S700 SoC device tree
  arm: add Cubieboard7 board support
  serial: actions: add uart support for s700
  actions: add Cubieboard7 README

 arch/arm/Kconfig |   2 -
 arch/arm/dts/s700-cubieboard7.dts|  39 ++
 arch/arm/dts/s700.dtsi   | 193 +++
 arch/arm/include/asm/arch-owl/clk_owl.h  |  61 +
 arch/arm/include/asm/arch-owl/clk_s900.h |  57 
 arch/arm/include/asm/arch-owl/regs_s700.h|  56 
 arch/arm/mach-owl/Kconfig|  31 ++---
 arch/arm/mach-owl/Makefile   |   3 +-
 arch/arm/mach-owl/README.cubieboard7 |  88 
 arch/arm/mach-owl/soc.c  |  56 
 arch/arm/mach-owl/sysmap-owl.c   |  32 +
 arch/arm/mach-owl/sysmap-s900.c  |  32 -
 board/ucRobotics/bubblegum_96/Kconfig|  15 ---
 board/ucRobotics/bubblegum_96/MAINTAINERS|   6 -
 board/ucRobotics/bubblegum_96/Makefile   |   3 -
 board/ucRobotics/bubblegum_96/bubblegum_96.c |  56 
 configs/bubblegum_96_defconfig   |   3 +-
 configs/cubieboard7_defconfig|  22 +++
 drivers/clk/owl/Kconfig  |   8 +-
 drivers/clk/owl/Makefile |   2 +-
 drivers/clk/owl/clk_owl.c| 132 ++
 drivers/clk/owl/clk_s900.c   | 137 ---
 drivers/serial/serial_owl.c  |   1 +
 include/configs/bubblegum_96.h   |  42 --
 include/configs/owl-common.h |  42 ++
 include/configs/s700.h   |  15 +++
 include/configs/s900.h   |  18 +++
 include/dt-bindings/clock/actions,s700-cmu.h | 118 
 28 files changed, 893 insertions(+), 377 deletions(-)
 create mode 100644 arch/arm/dts/s700-cubieboard7.dts
 create mode 100644 arch/arm/dts/s700.dtsi
 create mode 100644 arch/arm/include/asm/arch-owl/clk_owl.h
 delete mode 100644 arch/arm/include/asm/arch-owl/clk_s900.h
 create mode 100644 arch/arm/include/asm/arch-owl/regs_s700.h
 create mode 100644 arch/arm/mach-owl/README.cubieboard7
 create mode 100644 arch/arm/mach-owl/soc.c
 create mode 100644 arch/arm/mach-owl/sysmap-owl.c
 delete mode 100644 arch/arm/mach-owl/sysmap-s900.c
 delete mode 100644 board/ucRobotics/bubblegum_96/Kconfig
 delete mode 100644 board/ucRobotics/bubblegum_96/MAINTAINERS
 delete mode 100644 board/ucRobotics/bubblegum_96/Makefile
 delete mode 100644 board/ucRobotics/bubblegum_96/bubblegum_96.c
 create mode 100644 configs/cubieboard7_defconfig
 create mode 100644 drivers/clk/owl/clk_owl.c
 delete mode 100644 drivers/clk/owl/clk_s900.c
 delete mode 100644 include/configs/bubblegum_96.h
 create mode 100644 include/configs/owl-common.h
 create mode 100644 include/configs/s700.h
 create mode 100644 include/configs/s900.h
 create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h

-- 
2.7.4

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

[U-Boot] [PATCH] i2c: i2c-cdns: Use proper input frequency

[Michal Simek]

From: Tomasz Gorochowik 

This is needed to properly calculate i2c bus speed divisors.

Signed-off-by: Tomasz Gorochowik 
Signed-off-by: Wojciech Tatarski 
Signed-off-by: Michal Simek 
---

 drivers/i2c/i2c-cdns.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 30be173343dd..f2c4b2073c48 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* i2c register set */
 struct cdns_i2c_regs {
@@ -415,6 +416,8 @@ static int cdns_i2c_ofdata_to_platdata(struct udevice *dev)
struct i2c_cdns_bus *i2c_bus = dev_get_priv(dev);
struct cdns_i2c_platform_data *pdata =
(struct cdns_i2c_platform_data *)dev_get_driver_data(dev);
+   struct clk clk;
+   int ret;
 
i2c_bus->regs = (struct cdns_i2c_regs *)devfdt_get_addr(dev);
if (!i2c_bus->regs)
@@ -423,7 +426,11 @@ static int cdns_i2c_ofdata_to_platdata(struct udevice *dev)
if (pdata)
i2c_bus->quirks = pdata->quirks;
 
-   i2c_bus->input_freq = 1; /* TODO hardcode input freq for now */
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   i2c_bus->input_freq = clk_get_rate();
 
return 0;
 }
-- 
1.9.1

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

[U-Boot] [PATCH] arm64: zynqmp: Fix mmc node names to be in sync with kernel

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patches renames sd nodes in dts to be in line with
kernel. This patch also modifies the references for the same
in code.
It checks mmc first to have no time penalty for new DT node names based
on left-to-right expression evaluation.

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

 arch/arm/dts/zynqmp.dtsi | 4 ++--
 board/xilinx/zynqmp/zynqmp.c | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 80ac9a6ac7b0..831d6e1ecc4d 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -700,7 +700,7 @@
/* dma-coherent; */
};
 
-   sdhci0: sdhci@ff16 {
+   sdhci0: mmc@ff16 {
u-boot,dm-pre-reloc;
compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
@@ -715,7 +715,7 @@
nvmem-cell-names = "soc_revision";
};
 
-   sdhci1: sdhci@ff17 {
+   sdhci1: mmc@ff17 {
u-boot,dm-pre-reloc;
compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a";
status = "disabled";
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 1dcb26db95e1..41e88b03f9d1 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -588,6 +588,8 @@ int board_late_init(void)
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
+ "mmc@ff16", ) &&
+   uclass_get_device_by_name(UCLASS_MMC,
  "sdhci@ff16", )) {
puts("Boot from SD0 but without SD0 enabled!\n");
return -1;
@@ -604,6 +606,8 @@ int board_late_init(void)
case SD_MODE1:
puts("SD_MODE1\n");
if (uclass_get_device_by_name(UCLASS_MMC,
+ "mmc@ff17", ) &&
+   uclass_get_device_by_name(UCLASS_MMC,
  "sdhci@ff17", )) {
puts("Boot from SD1 but without SD1 enabled!\n");
return -1;
-- 
1.9.1

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

Re: [U-Boot] Issue faced due to "serial: Remove DM_FLAG_PRE_RELOC flag in various drivers" patch

[Lukasz Majewski]

Hi Priyanka,

> Hello,
> 
> I am working to add support for NXP LX2160ARDB board support"
> "https://patchwork.ozlabs.org/patch/1004541/;
> 
> For serial driver, we are using PL01X_SERIAL driver with DM_SERIAL
> enabled Since we need to support various clock frequencies, we have
> defined pl01x_serial_platdata in board file So it's a combination of
> CONFIG_DM_SERIAL + pl01x_serial_platdata
> 
> Also we have requirement to use serial driver before relocation as
> well.
> 
> Now with the patch  " serial: Remove DM_FLAG_PRE_RELOC flag in
> various drivers" the flag "DM_FLAG_PRE_RELOC" is no longer getting
> set resulting in UART driver not being available before relocation.
> 
> I tried adding "u-boot,dm-pre-reloc" in uart node, but it doesn't
> helped. [May be because uart nodes are set to disable to use
> 'pl01x_serial_platdata' method]
> 
> Can you please provide some suggestions on this issue.
> How to use "DM_SERIAL + pl01x_serial_platdata" feature in pre_reloc
> phase?

I'm not sure if this will help in your particular case, but I've got
similar issue with this flag.

Please see this patch and following discussion:
http://patchwork.ozlabs.org/patch/1019846/

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




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


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

[U-Boot] [PULL] Please pull u-boot-rockchip fixes for 2019.1

[Philipp Tomsich]

Tom,

Some additional fixes (Christoph’s series has been in-flight for a couple of 
weeks
due to my insistence on having pinctrl/regulators autoconfigured) for 2019.1.

The Travis-CI report is at 
https://travis-ci.org/ptomsich/u-boot-rockchip/builds/474593290

Thanks,
Philipp.


The following changes since commit f97c49d6a2f504d0f0a8aab37c67aa314e006250:

  Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-01-01 19:55:05 
-0500)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git tags/for-master-20190103

for you to fetch changes up to 77012e79ffc35994e5d6efca458d65bd03842b00:

  rockchip: rk3399-puma: Set VDD_LOG to 950 mV. (2019-01-02 22:40:02 +0100)


Last-minute fixes for 2019.1:
- clamp DRAM size to below 32bit for 32bit targets to support 4GB
- fix copyright notice on some Rockchip-contributed files
- adjust vdd_log for the RK3399-Q7 to improve stability in some workloads


Christoph Muellner (8):
  rockchip: rk3399-puma: Cleanup of vdd_log DTS entry.
  power: regulator: Allow PWM regulator to be omitted from SPL.
  rockchip: rk3399-puma: enable PWM regulator in Puma defconfig.
  dm: pinctrl: Add pinctrl_decode_pin_config_dm().
  rockchip: rk3399: Add improved pinctrl driver.
  rockchip: rk3399: Add Kconfig option for full pinctrl driver
  rockchip: rk3399-puma: enable full pinctrl driver in Puma defconfig.
  rockchip: rk3399-puma: Set VDD_LOG to 950 mV.

Kever Yang (3):
  rockchip: sdram-common: fix wrong size for 4GB in 32bit SoC
  rockchip: rk3036: ram: update license
  rockchip: ram: update license for sdram driver

 arch/arm/dts/rk3399-puma.dtsi|   5 +--
 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c |   4 +-
 arch/arm/mach-rockchip/sdram_common.c|  18 +
 configs/puma-rk3399_defconfig|   2 +
 drivers/pinctrl/Kconfig  |  10 +
 drivers/pinctrl/pinctrl-uclass.c |  22 ++
 drivers/pinctrl/rockchip/pinctrl_rk3399.c| 236 

 drivers/power/regulator/Kconfig  |   7 
 drivers/power/regulator/Makefile |   2 +-
 drivers/ram/rockchip/sdram_rk3128.c  |   2 +-
 drivers/ram/rockchip/sdram_rk3188.c  |   2 +-
 drivers/ram/rockchip/sdram_rk322x.c  |   2 +-
 drivers/ram/rockchip/sdram_rk3288.c  |   2 +-
 drivers/ram/rockchip/sdram_rk3328.c  |   2 +-
 drivers/ram/rockchip/sdram_rk3399.c  |   2 +-
 include/dm/pinctrl.h |  12 ++
 16 files changed, 317 insertions(+), 13 deletions(-)

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

Re: [U-Boot] Booting on RK3399

[Mark Kettenis]

> From: Simon Glass 
> Date: Wed, 2 Jan 2019 20:37:45 -0700
> 
> > Haven't tested flashing eMMC with rkdeveloptool myself, but that
> > should work on the firefly as well.
> >
> > Another complication as that the serial console speed defaults to
> > 150 which isn't supported by all serial-to-USB chips and frankly
> 
> Yes I seem to have one that supports this, so this is fine.

Just be aware that you'll need to patch TF-A to configure the serial
port to 150 as well.  Probably just a matter of changing
RK3399_BAUDRATE in plat/rockchip/rk3399/rk3399_def.h.

Cheers,

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

[U-Boot] Issue faced due to "serial: Remove DM_FLAG_PRE_RELOC flag in various drivers" patch

[Priyanka Jain]

Hello,

I am working to add support for NXP LX2160ARDB board support" 
"https://patchwork.ozlabs.org/patch/1004541/;

For serial driver, we are using PL01X_SERIAL driver with DM_SERIAL enabled
Since we need to support various clock frequencies, we have defined 
pl01x_serial_platdata in board file 
So it's a combination of CONFIG_DM_SERIAL + pl01x_serial_platdata

Also we have requirement to use serial driver before relocation as well.

Now with the patch  " serial: Remove DM_FLAG_PRE_RELOC flag in various drivers" 
the flag "DM_FLAG_PRE_RELOC" is no longer getting set resulting in UART driver 
not being available before relocation.

I tried adding "u-boot,dm-pre-reloc" in uart node, but it doesn't helped. [May 
be because uart nodes are set to disable to use 'pl01x_serial_platdata' method]

Can you please provide some suggestions on this issue.
How to use "DM_SERIAL + pl01x_serial_platdata" feature in pre_reloc phase?

Regards
Priyanka




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

Re: [U-Boot] [PATCH] board: mvebu: drop unused ETH_PHY macro definitions

[Stefan Roese]

On 02.01.19 17:26, Baruch Siach wrote:

These macros are not used anywhere in the boards code.

Cc: Chris Packham 
Cc: Dirk Eibach 
Cc: Mario Six 
Cc: Dennis Gilmore 
Signed-off-by: Baruch Siach 
---
  board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 4 
  board/Marvell/db-88f6820-gp/db-88f6820-gp.c   | 4 
  board/gdsys/a38x/controlcenterdc.c| 4 
  board/kobol/helios4/helios4.c | 4 
  board/solidrun/clearfog/clearfog.c| 4 
  5 files changed, 20 deletions(-)


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH u-boot 0/2] net: designware: add meson meson compatibles

[Neil Armstrong]

Hi Joe,

On 02/01/2019 22:01, Joe Hershberger wrote:
> On Fri, Nov 9, 2018 at 8:21 AM Neil Armstrong  wrote:
>>
>> Add the compatible strings in the Synopsys DWMAC driver for :
>> - The Amlogic GXBB (and other GX) SoC
>> - The Amlogic AXG (and other GX) SoC
>>
>> Neil Armstrong (2):
>>   net: designware: add meson meson gxbb comptatible
>>   net: designware: add meson meson axg compatible
> 
> Hi Neil,
> 
> Trying to catch up on patches - I don't see this series in patchwork -
> should it be?

I pushed them along the u-boot-amlogic-20181126 pull-request to tom.

Neil

> 
> Thanks,
> -Joe
> 

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

Re: [U-Boot] [PATCH 1/1] zynq: Kconfig: extend the bootstrap malloc() pool

[Michal Simek]

On 21. 12. 18 11:39, Anton Gerasimov wrote:
>> I have not a problem with this change but it has to be done based on
>> more information. It means you should look what requires that memory
>> and if make sense that these components need it at that time.
> 
> Thank you for  the advice, that was quite fruitful. So most of the
> heap (0x5f4 of 0x600) before the relocation is being consumed in
> device_bind_common function which binds device tree entries to
> the drivers.
> 
> If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not
> being used as far as I can see, it drops to 0x5a0, which lets the board
> boot, but still looks pretty tight. So maybe it's worth extending the heap
> anyway unless you need more information to take the decision.

I understand all of this but will be good to know what consumes that
0x5xx space and if we mark nodes properly that maybe something is not
used and we should remove that marking.

It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd
0xXXX, etc.

Thanks,
Michal



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

[U-Boot] [PATCH] cmd: Kconfig: LED command depends on LED subsystems

[Jan Kiszka]

From: Jan Kiszka 

Without CONFIG_LED, we get

cmd/built-in.o: In function `show_led_state':
cmd/led.c:40: undefined reference to `led_get_state'
cmd/built-in.o: In function `do_led':
cmd/led.c:99: undefined reference to `led_get_by_label'
cmd/led.c:108: undefined reference to `led_set_state'

Signed-off-by: Jan Kiszka 
---
 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325eb3..e1c0719165 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1399,6 +1399,7 @@ config CMD_DISPLAY
 
 config CMD_LED
bool "led"
+   depends on LED
default y if LED
help
  Enable the 'led' command which allows for control of LEDs supported
-- 
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] travis: Wire Xilinx Versal Virt platform

[Michal Simek]

On 26. 12. 18 15:29, Tom Rini wrote:
> On Thu, Dec 20, 2018 at 04:30:19PM +0800, Bin Meng wrote:
>> Hi Michal,
>>
>> On Thu, Dec 20, 2018 at 4:17 PM Michal Simek  wrote:
>>>
>>> On 20. 12. 18 9:09, Bin Meng wrote:
 On Thu, Dec 20, 2018 at 3:55 PM Michal Simek  
 wrote:
>
> Test Xilinx Versal Virt platform running on the v3.1.0 Qemu.
>
> Signed-off-by: Michal Simek 
> ---
>
> Patch needs to be applied when this PR is merged.
> https://github.com/swarren/uboot-test-hooks/pull/21
>
> ---
>  .travis.yml | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 6e4b4ba0a34a..e14e6987e4cf 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -454,6 +454,14 @@ matrix:
>QEMU_TARGET="arm-softmmu"
>TEST_PY_ID="--id qemu"
>BUILDMAN="^zynq_zc702$"
> +- name: "test/py xilinx_versal_virt"
> +  env:
> +- TEST_PY_BD="xilinx_versal_virt"
> +  TEST_PY_TEST_SPEC="not sleep"
> +  QEMU_TARGET="aarch64-softmmu"
> +  QEMU_VERSION="v3.1.0"
> +  TEST_PY_ID="--id qemu"
> +  BUILDMAN="^xilinx_versal_virt$"

 Can we turn on 3.1.0 for all QEMU targets?
>>>
>>> I expected this question.
>>> First of all I wanted to enable an option to be able to wire whatever
>>> version. Even sha1 for not released version.
>>>
>>> I think we can try to test v3.1.0 qemu version for all boards but I will
>>> let Tom to decide is we can move or not.
>>>
>>
>> Yes, please try to test that. If everything is good, I see no reason
>> not using it.
> 
> Yes, I would also like to move everyone up to v3.1.0 and also having the
> version we use be spelled out will help with future reproducibility.
> 

v3.1 is not working on vexpress_ca9x4 and vexpress_ca15_tc2.
take a look at https://travis-ci.org/michalsimek/u-boot/builds/470873127
I am happy to keep them on v3.0 and move the rest to v3.1 and let
vexpress guys to figured out what's wrong with v3.1 and configs around.

What do you think?

Thanks,
Michal


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