[U-Boot] [PULL] u-boot-usb/master

2016-03-04 Thread Marek Vasut 
Hi,

two minor fixes for 2016.03 . Thanks!

The following changes since commit 50dc8677d769be6e2b34f49b6c43ad1e977bdc51:

  Merge git://git.denx.de/u-boot-usb (2016-02-26 18:08:43 -0500)

are available in the git repository at:

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

for you to fetch changes up to b5ab663a6956e47180706b897bc9567335257d58:

  usb: dwc2: disable erroneous overcurrent condition (2016-03-05
02:21:36 +0100)


Dinh Nguyen (1):
  usb: dwc2: disable erroneous overcurrent condition

Sam Protsenko (1):
  usb: gadget: composite: Correct recovery path for register

 drivers/usb/gadget/composite.c | 8 +++-
 drivers/usb/host/dwc2.c| 4 +++-
 drivers/usb/host/dwc2.h| 2 ++
 3 files changed, 12 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv2] usb: dwc2: disable erroneous overcurrent condition

2016-03-04 Thread Marek Vasut 
On 03/05/2016 01:57 AM, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> For the case where an external VBUS is used, we should enable the external
> VBUS comparator in the driver. This would prevent an unnecessary overcurrent
> error which would then disable the host port.
> 
> The overcurrent condition was happening on the SoCFPGA Cyclone5 devkit, thus
> USB was not working on the devkit. This patch fixes that problem.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v2: consolidate bit OR into a single line

Applied, thanks!

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

[U-Boot] [PATCHv2] usb: dwc2: disable erroneous overcurrent condition

2016-03-04 Thread dinguyen 
From: Dinh Nguyen 

For the case where an external VBUS is used, we should enable the external
VBUS comparator in the driver. This would prevent an unnecessary overcurrent
error which would then disable the host port.

The overcurrent condition was happening on the SoCFPGA Cyclone5 devkit, thus
USB was not working on the devkit. This patch fixes that problem.

Signed-off-by: Dinh Nguyen 
---
v2: consolidate bit OR into a single line
---
 drivers/usb/host/dwc2.c |4 +++-
 drivers/usb/host/dwc2.h |2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index c6727c3..b2f4bc6 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -263,7 +263,9 @@ static void dwc_otg_core_init(struct dwc2_core_regs *regs)
 
/* Program the ULPI External VBUS bit if needed */
 #ifdef CONFIG_DWC2_PHY_ULPI_EXT_VBUS
-   usbcfg |= DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
+   usbcfg |= (DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV |
+  DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR |
+  DWC2_GUSBCFG_INDICATOR_PASSTHROUGH);
 #else
usbcfg &= ~DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
 #endif
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index 594757b..4482dc6 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -152,6 +152,8 @@ struct dwc2_core_regs {
 #define DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR_OFFSET21
 #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE (1 << 22)
 #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE_OFFSET  22
+#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH (1 << 24)
+#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH_OFFSET  24
 #define DWC2_GUSBCFG_IC_USB_CAP(1 << 26)
 #define DWC2_GUSBCFG_IC_USB_CAP_OFFSET 26
 #define DWC2_GUSBCFG_IC_TRAFFIC_PULL_REMOVE(1 << 27)
-- 
1.7.9.5

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

Re: [U-Boot] usb: dwc2: disable erroneous overcurrent condition

2016-03-04 Thread Marek Vasut 
On 03/04/2016 10:05 PM, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> For the case where an external VBUS is used, we should enable the external
> VBUS comparator in the driver. This would prevent an unnecessary overcurrent
> error which would then disable the host port.
> 
> The overcurrent condition was happening on the SoCFPGA Cyclone5 devkit, thus
> USB was not working on the devkit. This patch fixes that problem.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  drivers/usb/host/dwc2.c |2 ++
>  drivers/usb/host/dwc2.h |2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index c6727c3..d9a8d2d 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -264,6 +264,8 @@ static void dwc_otg_core_init(struct dwc2_core_regs *regs)
>   /* Program the ULPI External VBUS bit if needed */
>  #ifdef CONFIG_DWC2_PHY_ULPI_EXT_VBUS
>   usbcfg |= DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
> + usbcfg |= (DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR |
> +DWC2_GUSBCFG_INDICATOR_PASSTHROUGH);

Well why don't you wrap it into the previous usbcfg |= , one line above?

Can you send a V2 real quick or shall I fix it ?/

>  #else
>   usbcfg &= ~DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
>  #endif
> diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
> index 594757b..4482dc6 100644
> --- a/drivers/usb/host/dwc2.h
> +++ b/drivers/usb/host/dwc2.h
> @@ -152,6 +152,8 @@ struct dwc2_core_regs {
>  #define DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR_OFFSET  21
>  #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE   (1 << 22)
>  #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE_OFFSET22
> +#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH   (1 << 24)
> +#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH_OFFSET24
>  #define DWC2_GUSBCFG_IC_USB_CAP  (1 << 26)
>  #define DWC2_GUSBCFG_IC_USB_CAP_OFFSET   26
>  #define DWC2_GUSBCFG_IC_TRAFFIC_PULL_REMOVE  (1 << 27)
> 


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

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

2016-03-04 Thread Tom Rini 
... adding in devicetree-spec,
http://lists.denx.de/pipermail/u-boot/2016-February/246542.html for the
first part of this

On Fri, Feb 26, 2016 at 07:10:23PM -0600, Nishanth Menon wrote:
> Tom,
> 
> 
> On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini  wrote:
> > On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote:
> >> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini  wrote:
> >> > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
> [...]
> >> >
> >> > ... and this will match whatever is in the kernel, right?
> >>
> >> The Linux kernel will not need to access PMMC similar to how bootloader 
> >> has to.
> >>
> >> Bootloader looks to load up the peripheral - so, it's view of the
> >> hardware is as a programmable core (similar to how we'd look at a
> >> DSP/other remote proc), however, linux kernel only cares about the
> >> communication link (which is the message manager) and the protocol on
> >> top to communicate and does not need to access PMMC directly (it is
> >> only done once by bootloader).
> >>
> >> So the the current u-boot dt binding will not even need to be send
> >> upstream kernel, instead a protocol level definition (similar to SCPI)
> >> will be exposed to linux kernel.
> >
> > So is the kernel community going to be unhappy about getting what it
> > might consider extraneous information in the device tree?  The goal here
> > is to be able to just copy in the DT files from $upstream and really
> > really not have local changes without a good reason (and yes, we need to
> > revisit u-boot,dm-pre-reloc at some point).  Maybe a question for one of
> > the higher level DT lists...
> 
> Hmmm... I can switch to platform data if maintenance is an concern. I
> dont think PMMC will be an unique experience for DT view of the
> hardware where every  piece of software looks at things differently.
> For example: if we move DDR configuration to device tree (which dt is
> pretty capable of doing), then we are stuck with the same issue yet
> again. DDR configuration is not necessary for kernel device tree since
> it has nothing to do there - and we dont provide that information
> (since it becomes a maintenance pain in kernel world as well), but
> u-boot SPL will need to have that information.
> 
> Device tree is a representation of hardware is exactly what we do,
> except that view depends on what we need to expose to each software
> solution. Even in Linux, in a hypervisor world, a guest OS may only
> have access to certain peripherals of the SoC - we dont expose all the
> peripherals to the OS via dt, instead a custom guest OS dt view of the
> world is created. This is one problem we all have with DT -> the
> extent to which we "describe hardware" - there is no objective rules
> for the same that can get blindly applied..
> 
> Do let me know if I need to bring this device outside of dt into
> platform data world. It wont be my first preference, but if it does
> create a severe maintenance burden, then maybe that is what needs to
> happen -> only resources that are shared between kernel and bootloader
> can reside in dt... just my 2 cents..

So, I would like to see this particular bit stay in the DT, and I would
like to see this part of the DT not be only in the U-Boot tree but
rather the authorative DT which today resides in the Linux kernel.  But
I'm not the person to make that final call, so adding in more people
here.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] usb: dwc2: disable erroneous overcurrent condition

2016-03-04 Thread dinguyen 
From: Dinh Nguyen 

For the case where an external VBUS is used, we should enable the external
VBUS comparator in the driver. This would prevent an unnecessary overcurrent
error which would then disable the host port.

The overcurrent condition was happening on the SoCFPGA Cyclone5 devkit, thus
USB was not working on the devkit. This patch fixes that problem.

Signed-off-by: Dinh Nguyen 
---
 drivers/usb/host/dwc2.c |2 ++
 drivers/usb/host/dwc2.h |2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index c6727c3..d9a8d2d 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -264,6 +264,8 @@ static void dwc_otg_core_init(struct dwc2_core_regs *regs)
/* Program the ULPI External VBUS bit if needed */
 #ifdef CONFIG_DWC2_PHY_ULPI_EXT_VBUS
usbcfg |= DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
+   usbcfg |= (DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR |
+  DWC2_GUSBCFG_INDICATOR_PASSTHROUGH);
 #else
usbcfg &= ~DWC2_GUSBCFG_ULPI_EXT_VBUS_DRV;
 #endif
diff --git a/drivers/usb/host/dwc2.h b/drivers/usb/host/dwc2.h
index 594757b..4482dc6 100644
--- a/drivers/usb/host/dwc2.h
+++ b/drivers/usb/host/dwc2.h
@@ -152,6 +152,8 @@ struct dwc2_core_regs {
 #define DWC2_GUSBCFG_ULPI_INT_VBUS_INDICATOR_OFFSET21
 #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE (1 << 22)
 #define DWC2_GUSBCFG_TERM_SEL_DL_PULSE_OFFSET  22
+#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH (1 << 24)
+#define DWC2_GUSBCFG_INDICATOR_PASSTHROUGH_OFFSET  24
 #define DWC2_GUSBCFG_IC_USB_CAP(1 << 26)
 #define DWC2_GUSBCFG_IC_USB_CAP_OFFSET 26
 #define DWC2_GUSBCFG_IC_TRAFFIC_PULL_REMOVE(1 << 27)
-- 
1.7.9.5

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

[U-Boot] [PATCH] sunxi: video: Configure only LVDS pins instead of all LCD pins when LVDS interface selected

2016-03-04 Thread Lawrence Yu 
The behavior before this patch would attempt to configure the mux
setting for pins 0 to 27 on PORTD to all be setting 3 for LVDS.  The
LVDS interface actually only uses pins 18 to 27 and not pins 0 to 27
as in the parallel LCD interface.  This patch restricts the
configuration to only the relevant pins 18 to 27 on PORTD.

This was tested on a sun8i A33 tablet with an LVDS screen.  MMC1 has
the capability to use pins 2 to 7 on PORTD and the mux on those pins
was being inadvertently set to setting 3 for MMC functionality which
this patch corrects.

Signed-off-by: Lawrence Yu 
---

 drivers/video/sunxi_display.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 9fee66a..3674ae1 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -767,7 +767,11 @@ static void sunxi_lcdc_tcon0_mode_set(const struct 
ctfb_res_modes *mode,
(struct sunxi_lcdc_reg *)SUNXI_LCD0_BASE;
int bp, clk_delay, clk_div, clk_double, pin, total, val;
 
+#ifdef CONFIG_VIDEO_LCD_IF_LVDS
+   for (pin = SUNXI_GPD(18); pin <= SUNXI_GPD(27); pin++) {
+#else
for (pin = SUNXI_GPD(0); pin <= SUNXI_GPD(27); pin++) {
+#endif
 #ifdef CONFIG_VIDEO_LCD_IF_PARALLEL
sunxi_gpio_set_cfgpin(pin, SUNXI_GPD_LCD0);
 #endif
-- 
2.5.3

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

2016-03-04 Thread Marek Vasut 
On 03/04/2016 05:06 PM, Dinh Nguyen wrote:
> On 03/02/2016 05:24 PM, Marek Vasut wrote:
>> On 03/03/2016 12:08 AM, Dinh Nguyen wrote:
>>> On 03/02/2016 04:54 PM, Dinh Nguyen wrote:
 CC: Marek Vasut

 On 03/01/2016 08:40 PM, George Broz wrote:
> On 17 February 2016 at 18:45, Phil Reid  wrote:
>> G'day George
>>
>>
>> On 18/02/2016 5:54 AM, George Broz wrote:
>>>
>>> Hello,
>>>
>>> Sorry for the newbie question...
>>>
>>> I have an Altera/Terasic board (socfpga_sockit) that has issues
>>> recognizing
>>> USB storage devices (roughly 60% good / 40% bad):
>>>
>
>>> If I try a later release (e.g. v2016.01 which seems to support the 
>>> Terasic
>>> board explicitly) the boot process stops just after loading the SPL.
>>>
>>> At this point I have only been changing the u-boot.img component, not 
>>> the
>>> SPL (in the a2 partition of the MMC).
>>>
>>> The documentation from Altera about generating the SPL seems to require
>>> using Qsys/Quartus tools which I'd really like to avoid.
>>>
>>> I can produce u-boot-spl.bin / u-boot.img from
>>> make socfpga_sockit_defconfig; make all.
>>>
>>> My newbie question ... should be I able to use directly the 
>>> u-boot-spl.bin
>>> generated by the build to replace the SPL on the board?
>>>
>>
>> I've just gone thru the process (this week) of getting uboot 2016.01 to 
>> boot
>> on our custom socfpga board.
>> There where a few issues in getting things going.
>> If your using the sd card to boot then the current memory layout is not 
>> per
>> the altera documentation.
>> I had to make the changes below to config to match the altera docs.
>> Otherwise it hangs just after the SPL.
>> You also need to use the -dtb image versions with 2016.01 for things to
>> work.
>> Again you may need to make sure the uboot device trees match your 
>> hardware.
>> Not all uboot drivers appear to be using the DT as yet.
>>
>> Note the SPL is tightly coupled to the board design and potentially the 
>> FPGA
>> image.
>> If you using bridges or routing HPS resources (eg i2c etc) to the fpga 
>> the
>> SPL configures the muxes.
>>
>> There's a script in uboot src at arch\arm\mach-socfpga\qts-filter.sh
>> That will generate the qts files for you arch.
>>
>> I haven't tried the USB stuff as yet.
>> There are some issues witht eh altera USB port trigger an Over Current 
>> event
>> on device insertation.
>> They've modified the linux kenerl driver to use external OV current
>> detection to get around the problem.
>> My intial workaround was to insert USB device prior to power on.
>> I haven't looked at the uboot USB driver yet to see what's in there.
>>
>>
>> --
>> Regards
>> Phil Reid
>>
>>
>> diff --git a/include/configs/socfpga_common.h
>> b/include/configs/socfpga_common.h
>> index a09e906..3a1b59b 100644 (file)
>> --- a/include/configs/socfpga_common.h
>> +++ b/include/configs/socfpga_common.h
>> @@ -357,13 +357,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>>
>> /* SPL SDMMC boot support */
>> #ifdef CONFIG_SPL_MMC_SUPPORT
>> +#define CONFIG_SPL_LIBDISK_SUPPORT
>> #if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
>> #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 2
>> #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"
>> -#define CONFIG_SPL_LIBDISK_SUPPORT
>> #else
>> -#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 3
>> -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0xa00 /* offset 2560 
>> sect
>> (1M+256k) */
>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 3
>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200
>> #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
>> #endif
>> #endif
>>
>>
>
> Thanks, Phil!
>
> Sorry for the delayed response - got called away, but am back to this
> now. I patched
> socfpga_common.h and re-built the project. I picked up
> spl/u-boot-spl-dtb.sfp and
> u-boot-dtb.img and transferred them to the SD card with:
>
> dd if=u-boot-spl-dtb.sfp of=/dev/sdf3 bs=64k seek=0
> dd if=u-boot-dtb.img of=/dev/sdf3 bs=64k seek=4
>

 You can just do a 'make u-boot-with-spl.sfp' and burn the
 u-boot-with-spl.sfp file straight to the a2 partition, or sdf3.

> Tried this with both the original DT set (socfpga.dtsi, 
> socfpga_cyclone.dtsi,
> socfpga_cyclone5_sockit.dts) that came with the u-boot v2016.01 download 
> and
> also an Altera-patched DT set that I've used to boot into Linux numerous 
> times.
>
> When I start up the board I get:
>
> U-Boot SPL 2016.01 (Mar 01 2016 - 17:28:14)
>

Re: [U-Boot] [PATCH] malloc: handle free() before gd is set

2016-03-04 Thread Stephen Warren 

On 03/04/2016 01:45 AM, Hans de Goede wrote:

Hi,

On 04-03-16 09:19, Stephen Warren wrote:

On at least Ubuntu Xenial, free() can be called before main(). In this
case, U-Boot won't have set gd, so dereferencing it will crash. Check
whether gd is set before using it.

While at it, apply the same fix to other functions.

Signed-off-by: Stephen Warren 
---
  common/dlmalloc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 5ea37dfb6e4c..7453e63d6bf4 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -2453,7 +2453,7 @@ void fREe(mem) Void_t* mem;

  #ifdef CONFIG_SYS_MALLOC_F_LEN
  /* free() is a no-op - all the memory will be freed on
relocation */
-if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
  return;
  #endif



I believe you want:

+if (!gd || !(gd->flags & GD_FLG_FULL_MALLOC_INIT))

Instead, so that you actually go into the return; path when there is no gd.


Hmm. Is the existing logic at the start of malloc() (which I copied) 
incorrect too then? Perhaps so...


#ifdef CONFIG_SYS_MALLOC_F_LEN
  if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
return malloc_simple(bytes);
#endif

  /* check if mem_malloc_init() was run */
  if ((mem_malloc_start == 0) && (mem_malloc_end == 0)) {
/* not initialized yet */
return NULL;
  }

I guess that works because "if (gd && ..." prevents gd from being 
dereferenced, but doesn't actually return, and then presumably 
"(mem_malloc_start == 0) && (mem_malloc_end == 0)" is true at that 
point, so the function returns NULL immediately anyway.


For free() after my change:

#ifdef CONFIG_SYS_MALLOC_F_LEN
  /* free() is a no-op - all the memory will be freed on relocation */
  if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
return;
#endif

  if (mem == NULL) /* free(0) has no effect */
return;

I guess that "mem == NULL" is always true, since malloc() always 
returned NULL, so everything works out somewhat accidentally in a 
similar way. Still, as you say it's probably better to be a bit more 
direct and add an explicit guard in malloc on gd leaving it:


+ if (!gd)
+   return NULL;
  #ifdef CONFIG_SYS_MALLOC_F_LEN
-   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)
  return malloc_simple(bytes);
  #endif

and free:

+ if (!gd)
+   return;

Or perhaps actually using malloc_simple() if (!gd) is the better option, 
since obviously something[1] is actually trying to allocate memory?


[1] IIRC something in the dynamic loader, but I forget the complete 
backtrace right now.

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

2016-03-04 Thread Dinh Nguyen 
On 03/03/2016 04:09 PM, Marek Vasut wrote:
> On 03/03/2016 11:00 PM, George Broz wrote:
>> On 3 March 2016 at 06:51, Marek Vasut  wrote:
>>> On 03/03/2016 03:48 PM, Dinh Nguyen wrote:


 On 03/02/2016 05:24 PM, Marek Vasut wrote:
>
> Well, that's our usual USB/QSPI cache issue that's tormenting your soul.
> CCing Chin ;-)
>
> Does the issue by any chance magically disappear if you apply this patch:
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 026e7ef..06802c6 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -274,7 +274,7 @@ static inline void set_dacr(unsigned int val)
>
>  /* options available for data cache on each page */
>  enum dcache_option {
> -   DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
> +   DCACHE_OFF = TTB_SECT_S_MASK | TTB_SECT_DOMAIN(0) |
> TTB_SECT_XN_MASK | TTB_SECT,
> DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
> DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
> DCACHE_WRITEALLOC = DCACHE_WRITEBACK | TTB_SECT_TEX(1),
>
>>
>> The 2016.01 code I'm using already includes this patch. If I try
>> reading a USB stick with dcache on or off
>> I get the same result:
>>
>> => dcache off
>> => usb reset
>> resetting USB...
>> USB0:   Core Release: 2.93a
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> dwc_otg_core_host_init: Timeout!
>> scanning bus 0 for devices... 1 USB Device(s) found
>> => usb tree
>> USB device tree:
>>   1  Hub (480 Mb/s, 0mA)
>>   U-Boot Root Hub
> 
> This more likely means that either clock or reset bits are not
> configured correctly OR you're using the wrong controller. Since
> you're mixing old U-Boot SPL with new U-Boot, there can be some
> discrepancy and I have no idea how to help you with that :(
> 

Can you try these steps?

1)Boot up
2)"dcache off"
3)"mw.l 0xffb40440 0x1000 1"
4)"usb start"

On the devkit, it seems that the USB port power bit is not getting
turned on, so it's failing to detect the USB device. You can probably
ignore stop 2, if you already Marek's patch.

Dinh

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

[U-Boot] [PATCH V2 0/6] ARM: keystone2: Miscellaneous fixes

2016-03-04 Thread Nishanth Menon 
Hi,
Please find various fixes for DDR, DSP and speed grade operations
w.r.t Keystone devices

Based on   master 52dd704bf8ed Merge branch 'master' of 
http://git.denx.de/u-boot-sunxi 

Changes in V2:
- updates to patch #5 (review comments)
- picked up reviewed by

V1: http://marc.info/?l=u-boot=145641557719622=2
Lokesh Vutla (2):
  ARM: keystone2: Allow for board specific speed definitions
  ARM: keystone2: K2G: Add support for different arm/device speeds

Suman Anna (2):
  ARM: keystone2: Use macro for DSP GEM power domain
  ARM: keystone2: K2G: power-off DSP during boot

Vitaly Andrianov (2):
  ARM: keystone2: use SPD info to configure K2HK and K2E DDR3
  ARM: keystone2: use detected ddr3a size

 arch/arm/mach-keystone/Makefile|   2 +
 arch/arm/mach-keystone/clock.c |  19 +-
 arch/arm/mach-keystone/ddr3_spd.c  | 463 +
 arch/arm/mach-keystone/include/mach/clock-k2g.h|   4 +-
 arch/arm/mach-keystone/include/mach/clock.h|   8 +-
 arch/arm/mach-keystone/include/mach/ddr3.h |   9 +
 arch/arm/mach-keystone/include/mach/hardware-k2g.h |   7 +-
 arch/arm/mach-keystone/include/mach/hardware-k2l.h |   7 +
 arch/arm/mach-keystone/include/mach/hardware.h |   1 +
 arch/arm/mach-keystone/keystone.c  |   2 +-
 board/ti/ks2_evm/Makefile  |   4 +-
 board/ti/ks2_evm/board.c   |   4 +-
 board/ti/ks2_evm/board_k2e.c   |   2 +-
 board/ti/ks2_evm/board_k2g.c   |  50 ++-
 board/ti/ks2_evm/board_k2hk.c  |   4 +-
 board/ti/ks2_evm/board_k2l.c   |   4 +-
 board/ti/ks2_evm/ddr3_cfg.c| 159 +--
 board/ti/ks2_evm/ddr3_cfg.h|  11 +-
 board/ti/ks2_evm/ddr3_k2e.c|  51 +--
 board/ti/ks2_evm/ddr3_k2hk.c   |  97 ++---
 include/configs/k2e_evm.h  |   2 +
 include/configs/k2hk_evm.h |   2 +
 22 files changed, 625 insertions(+), 287 deletions(-)
 create mode 100644 arch/arm/mach-keystone/ddr3_spd.c

-- 
2.7.0

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

[U-Boot] [PATCH V2 2/6] ARM: keystone2: K2G: power-off DSP during boot

2016-03-04 Thread Nishanth Menon 
From: Suman Anna 

The DSPs are powered on by default upon a Power ON reset, and
they are powered off on current Keystone 2 SoCs - K2HK, K2L, K2E
during the boot in u-boot. This is not functional on K2G though.
Extend the existing DSP power-off support to the only DSP present
on K2G. Do note that the PSC clock domain module id for DSP on K2G
differs from that of previous Keystone2 SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588157/

 arch/arm/mach-keystone/include/mach/hardware-k2g.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2g.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
index fa4162fe9964..ca2a119d3901 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
@@ -10,7 +10,7 @@
 #ifndef __ASM_ARCH_HARDWARE_K2G_H
 #define __ASM_ARCH_HARDWARE_K2G_H
 
-#define KS2_NUM_DSPS   0
+#define KS2_NUM_DSPS   1
 
 /* Power and Sleep Controller (PSC) Domains */
 #define KS2_LPSC_ALWAYSON  0
@@ -30,7 +30,10 @@
 #define KS2_LPSC_MCASP 15
 #define KS2_LPSC_SR16
 #define KS2_LPSC_MSMC  17
-#define KS2_LPSC_GEM   18
+#ifdef KS2_LPSC_GEM_0
+#undef KS2_LPSC_GEM_0
+#endif
+#define KS2_LPSC_GEM_0 18
 #define KS2_LPSC_ARM   19
 #define KS2_LPSC_ASRC  20
 #define KS2_LPSC_ICSS  21
-- 
2.7.0

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

[U-Boot] [PATCH V2 5/6] ARM: keystone2: use SPD info to configure K2HK and K2E DDR3

2016-03-04 Thread Nishanth Menon 
From: Vitaly Andrianov 

This commit replaces hard-coded EMIF and PHY DDR3 configurations for
predefined SODIMMs to a calculated configuration. The SODIMM parameters
are read from SODIMM's SPD and used to calculated the configuration.

The current commit supports calculation for DDR3 with 1600MHz and 1333MHz
only.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
Changes in V2:
- Updated copyright to include 2016
- remoted puts and replaced with printf
- debug print now made with debug_cond like common/cli_simple.c

V1: https://patchwork.ozlabs.org/patch/588161/

 arch/arm/mach-keystone/Makefile|   2 +
 arch/arm/mach-keystone/ddr3_spd.c  | 453 +
 arch/arm/mach-keystone/include/mach/ddr3.h |   8 +
 board/ti/ks2_evm/Makefile  |   4 +-
 board/ti/ks2_evm/ddr3_cfg.c| 159 +-
 board/ti/ks2_evm/ddr3_cfg.h|  11 +-
 board/ti/ks2_evm/ddr3_k2e.c|  51 ++--
 board/ti/ks2_evm/ddr3_k2hk.c   |  97 +++---
 include/configs/k2e_evm.h  |   2 +
 include/configs/k2hk_evm.h |   2 +
 10 files changed, 529 insertions(+), 260 deletions(-)
 create mode 100644 arch/arm/mach-keystone/ddr3_spd.c

diff --git a/arch/arm/mach-keystone/Makefile b/arch/arm/mach-keystone/Makefile
index ffd9eadb0a49..9713fe4d6858 100644
--- a/arch/arm/mach-keystone/Makefile
+++ b/arch/arm/mach-keystone/Makefile
@@ -13,3 +13,5 @@ obj-y += cmd_mon.o
 obj-y  += msmc.o
 obj-y  += ddr3.o cmd_ddr3.o
 obj-y  += keystone.o
+obj-$(CONFIG_K2E_EVM) += ddr3_spd.o
+obj-$(CONFIG_K2HK_EVM) += ddr3_spd.o
diff --git a/arch/arm/mach-keystone/ddr3_spd.c 
b/arch/arm/mach-keystone/ddr3_spd.c
new file mode 100644
index ..e5018c9eb669
--- /dev/null
+++ b/arch/arm/mach-keystone/ddr3_spd.c
@@ -0,0 +1,453 @@
+/*
+ * Keystone2: DDR3 SPD configuration
+ *
+ * (C) Copyright 2015-2016 Texas Instruments Incorporated, 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define DUMP_DDR_CONFIG0   /* set to 1 to debug */
+#define debug_ddr_cfg(fmt, args...)\
+  debug_cond(DUMP_DDR_CONFIG, fmt, ##args)
+
+static void dump_phy_config(struct ddr3_phy_config *ptr)
+{
+   debug_ddr_cfg("\npllcr  0x%08X\n", ptr->pllcr);
+   debug_ddr_cfg("pgcr1_mask   0x%08X\n", ptr->pgcr1_mask);
+   debug_ddr_cfg("pgcr1_val0x%08X\n", ptr->pgcr1_val);
+   debug_ddr_cfg("ptr0 0x%08X\n", ptr->ptr0);
+   debug_ddr_cfg("ptr1 0x%08X\n", ptr->ptr1);
+   debug_ddr_cfg("ptr2 0x%08X\n", ptr->ptr2);
+   debug_ddr_cfg("ptr3 0x%08X\n", ptr->ptr3);
+   debug_ddr_cfg("ptr4 0x%08X\n", ptr->ptr4);
+   debug_ddr_cfg("dcr_mask 0x%08X\n", ptr->dcr_mask);
+   debug_ddr_cfg("dcr_val  0x%08X\n", ptr->dcr_val);
+   debug_ddr_cfg("dtpr00x%08X\n", ptr->dtpr0);
+   debug_ddr_cfg("dtpr10x%08X\n", ptr->dtpr1);
+   debug_ddr_cfg("dtpr20x%08X\n", ptr->dtpr2);
+   debug_ddr_cfg("mr0  0x%08X\n", ptr->mr0);
+   debug_ddr_cfg("mr1  0x%08X\n", ptr->mr1);
+   debug_ddr_cfg("mr2  0x%08X\n", ptr->mr2);
+   debug_ddr_cfg("dtcr 0x%08X\n", ptr->dtcr);
+   debug_ddr_cfg("pgcr20x%08X\n", ptr->pgcr2);
+   debug_ddr_cfg("zq0cr1   0x%08X\n", ptr->zq0cr1);
+   debug_ddr_cfg("zq1cr1   0x%08X\n", ptr->zq1cr1);
+   debug_ddr_cfg("zq2cr1   0x%08X\n", ptr->zq2cr1);
+   debug_ddr_cfg("pir_v1   0x%08X\n", ptr->pir_v1);
+   debug_ddr_cfg("pir_v2   0x%08X\n\n", ptr->pir_v2);
+};
+
+static void dump_emif_config(struct ddr3_emif_config *ptr)
+{
+   debug_ddr_cfg("\nsdcfg  0x%08X\n", ptr->sdcfg);
+   debug_ddr_cfg("sdtim1   0x%08X\n", ptr->sdtim1);
+   debug_ddr_cfg("sdtim2   0x%08X\n", ptr->sdtim2);
+   debug_ddr_cfg("sdtim3   0x%08X\n", ptr->sdtim3);
+   debug_ddr_cfg("sdtim4   0x%08X\n", ptr->sdtim4);
+   debug_ddr_cfg("zqcfg0x%08X\n", ptr->zqcfg);
+   debug_ddr_cfg("sdrfc0x%08X\n\n", ptr->sdrfc);
+};
+
+#define TEMP NORMAL_TEMP
+#define VBUS_CLKPERIOD 1.875 /* Corresponds to vbus=533MHz, */
+#define PLLGS_VAL  (4000.0 / VBUS_CLKPERIOD) /* 4 us */
+#define PLLPD_VAL  (1000.0 / VBUS_CLKPERIOD) /* 1 us */
+#define PLLLOCK_VAL(10.0 / VBUS_CLKPERIOD) /* 100 us */
+#define PLLRST_VAL (9000.0 / VBUS_CLKPERIOD) /* 9 us */
+#define PHYRST_VAL 0x10
+#define DDR_TERM RZQ_4_TERM
+#define SDRAM_DRIVE RZQ_7_IMP
+#define DYN_ODT ODT_DISABLE
+
+enum srt {
+   NORMAL_TEMP,
+   EXTENDED_TEMP
+};
+

[U-Boot] [PATCH V2 4/6] ARM: keystone2: K2G: Add support for different arm/device speeds

2016-03-04 Thread Nishanth Menon 
From: Lokesh Vutla 

The maximum device and arm speeds can be determined by reading
EFUSE_BOOTROM register. As there is already a framework for reading this
register, adding support for all possible speeds on k2g devices.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588156/

 arch/arm/mach-keystone/clock.c  |  7 +++-
 arch/arm/mach-keystone/include/mach/clock-k2g.h |  4 +-
 arch/arm/mach-keystone/include/mach/clock.h |  4 ++
 board/ti/ks2_evm/board_k2g.c| 50 +++--
 4 files changed, 57 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-keystone/clock.c b/arch/arm/mach-keystone/clock.c
index 1ae3baf982a1..b25db1e3fede 100644
--- a/arch/arm/mach-keystone/clock.c
+++ b/arch/arm/mach-keystone/clock.c
@@ -238,8 +238,11 @@ static int get_max_speed(u32 val, u32 speed_supported, int 
*spds)
return spds[speed];
}
 
-   /* If no bit is set, use SPD800 */
-   return SPD800;
+   /* If no bit is set, return minimum speed */
+   if (cpu_is_k2g())
+   return SPD200;
+   else
+   return SPD800;
 }
 
 static inline u32 read_efuse_bootrom(void)
diff --git a/arch/arm/mach-keystone/include/mach/clock-k2g.h 
b/arch/arm/mach-keystone/include/mach/clock-k2g.h
index 214c1d3a8360..74de6202fe50 100644
--- a/arch/arm/mach-keystone/include/mach/clock-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/clock-k2g.h
@@ -12,8 +12,8 @@
 
 #define PLLSET_CMD_LIST""
 
-#define DEV_SUPPORTED_SPEEDS   0xfff
-#define ARM_SUPPORTED_SPEEDS   0xfff
+#define DEV_SUPPORTED_SPEEDS   0x1ff
+#define ARM_SUPPORTED_SPEEDS   0xff
 
 #define KS2_CLK1_6 sys_clk0_6_clk
 
diff --git a/arch/arm/mach-keystone/include/mach/clock.h 
b/arch/arm/mach-keystone/include/mach/clock.h
index dfebcb03ea57..72724aa4a912 100644
--- a/arch/arm/mach-keystone/include/mach/clock.h
+++ b/arch/arm/mach-keystone/include/mach/clock.h
@@ -63,8 +63,12 @@
 #define CLOCK_INDEXES_LIST CLK_LIST(GENERATE_INDX_STR)
 
 enum {
+   SPD200,
+   SPD400,
+   SPD600,
SPD800,
SPD850,
+   SPD900,
SPD1000,
SPD1200,
SPD1250,
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index cdeb056a76c4..b62c41225039 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -23,22 +23,64 @@ unsigned int external_clk[ext_clk_count] = {
[uart_clk]  =   SYS_CLK,
 };
 
-static struct pll_init_data main_pll_config = {MAIN_PLL, 100, 1, 4};
-static struct pll_init_data tetris_pll_config = {TETRIS_PLL, 100, 1, 4};
+static int arm_speeds[DEVSPEED_NUMSPDS] = {
+   SPD400,
+   SPD600,
+   SPD800,
+   SPD900,
+   SPD1000,
+   SPD900,
+   SPD800,
+   SPD600,
+   SPD400,
+   SPD200,
+};
+
+static int dev_speeds[DEVSPEED_NUMSPDS] = {
+   SPD600,
+   SPD800,
+   SPD900,
+   SPD1000,
+   SPD900,
+   SPD800,
+   SPD600,
+   SPD400,
+};
+
+static struct pll_init_data main_pll_config[NUM_SPDS] = {
+   [SPD400]= {MAIN_PLL, 100, 3, 2},
+   [SPD600]= {MAIN_PLL, 300, 6, 2},
+   [SPD800]= {MAIN_PLL, 200, 3, 2},
+   [SPD900] =  {TETRIS_PLL, 75, 1, 2},
+   [SPD1000] = {TETRIS_PLL, 250, 3, 2},
+};
+
+static struct pll_init_data tetris_pll_config[NUM_SPDS] = {
+   [SPD200] =  {TETRIS_PLL, 250, 3, 10},
+   [SPD400] =  {TETRIS_PLL, 100, 1, 6},
+   [SPD600] =  {TETRIS_PLL, 100, 1, 4},
+   [SPD800] =  {TETRIS_PLL, 400, 3, 4},
+   [SPD900] =  {TETRIS_PLL, 75, 1, 2},
+   [SPD1000] = {TETRIS_PLL, 250, 3, 2},
+};
+
 static struct pll_init_data uart_pll_config = {UART_PLL, 64, 1, 4};
 static struct pll_init_data nss_pll_config = {NSS_PLL, 250, 3, 2};
 static struct pll_init_data ddr3_pll_config = {DDR3A_PLL, 250, 3, 10};
 
 struct pll_init_data *get_pll_init_data(int pll)
 {
+   int speed;
struct pll_init_data *data = NULL;
 
switch (pll) {
case MAIN_PLL:
-   data = _pll_config;
+   speed = get_max_dev_speed(dev_speeds);
+   data = _pll_config[speed];
break;
case TETRIS_PLL:
-   data = _pll_config;
+   speed = get_max_arm_speed(arm_speeds);
+   data = _pll_config[speed];
break;
case NSS_PLL:
data = _pll_config;
-- 
2.7.0

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

[U-Boot] [PATCH V2 6/6] ARM: keystone2: use detected ddr3a size

2016-03-04 Thread Nishanth Menon 
From: Vitaly Andrianov 

Because KS2 u-boot works in 32 bit address space the existing ram_size
global data field cannot be used. The maximum, which the get_ram_size()
can detect is 2GB only. The ft_board_setup() needs the actual ddr3 size
to fix up dtb.

This commit introduces the ddr3_get_size() which uses SPD data to
calculate the ddr3 size. This function replaces the "ddr3_size"
environment variable, which was used to get the SODIMM size.

For platforms, which don't have SODIMM with SPD and ddr3 is populated to
a board a simple ddr3_get_size function that returns ddr3 size has to be
implemented. See hardware-k2l.h

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588160/

 arch/arm/mach-keystone/ddr3_spd.c  | 10 ++
 arch/arm/mach-keystone/include/mach/ddr3.h |  1 +
 arch/arm/mach-keystone/include/mach/hardware-k2l.h |  7 +++
 board/ti/ks2_evm/board.c   |  4 +---
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-keystone/ddr3_spd.c 
b/arch/arm/mach-keystone/ddr3_spd.c
index e5018c9eb669..c54188678707 100644
--- a/arch/arm/mach-keystone/ddr3_spd.c
+++ b/arch/arm/mach-keystone/ddr3_spd.c
@@ -426,6 +426,16 @@ static int ddr3_read_spd(ddr3_spd_eeprom_t *spd_params)
return 0;
 }
 
+int ddr3_get_size(void)
+{
+   ddr3_spd_eeprom_t spd_params;
+
+   if (ddr3_read_spd(_params))
+   return 0;
+
+   return ddr3_get_size_in_mb(_params) / 1024;
+}
+
 int ddr3_get_dimm_params_from_spd(struct ddr3_spd_cb *spd_cb)
 {
struct ddr3_sodimm spd;
diff --git a/arch/arm/mach-keystone/include/mach/ddr3.h 
b/arch/arm/mach-keystone/include/mach/ddr3.h
index 68d3cb4245e9..5feffe825b97 100644
--- a/arch/arm/mach-keystone/include/mach/ddr3.h
+++ b/arch/arm/mach-keystone/include/mach/ddr3.h
@@ -66,5 +66,6 @@ void ddr3_err_reset_workaround(void);
 void ddr3_enable_ecc(u32 base, int test);
 void ddr3_init_ddrphy(u32 base, struct ddr3_phy_config *phy_cfg);
 void ddr3_init_ddremif(u32 base, struct ddr3_emif_config *emif_cfg);
+int ddr3_get_size(void);
 
 #endif
diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2l.h 
b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
index 4f1197ea923d..a59e0713593f 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2l.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2l.h
@@ -105,4 +105,11 @@
 /* NETCP */
 #define KS2_NETCP_BASE 0x2600
 
+#ifndef __ASSEMBLY__
+static inline int ddr3_get_size(void)
+{
+   return 2;
+}
+#endif
+
 #endif /* __ASM_ARCH_HARDWARE_K2L_H */
diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 7d1709c880af..ca668a7c6902 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -146,9 +146,7 @@ int ft_board_setup(void *blob, bd_t *bd)
 
ddr3a_size = 0;
if (lpae) {
-   env = getenv("ddr3a_size");
-   if (env)
-   ddr3a_size = simple_strtol(env, NULL, 10);
+   ddr3a_size = ddr3_get_size();
if ((ddr3a_size != 8) && (ddr3a_size != 4))
ddr3a_size = 0;
}
-- 
2.7.0

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

[U-Boot] [PATCH V2 1/6] ARM: keystone2: Use macro for DSP GEM power domain

2016-03-04 Thread Nishanth Menon 
From: Suman Anna 

Define a macro for the DSP GEM power domain id number and
use it instead of a hard-coded number in the code that
disables all the DSPs on various Keystone2 SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588158/

 arch/arm/mach-keystone/include/mach/hardware.h | 1 +
 arch/arm/mach-keystone/keystone.c  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-keystone/include/mach/hardware.h 
b/arch/arm/mach-keystone/include/mach/hardware.h
index edebcd7bc587..8ca19bbcdbe9 100644
--- a/arch/arm/mach-keystone/include/mach/hardware.h
+++ b/arch/arm/mach-keystone/include/mach/hardware.h
@@ -160,6 +160,7 @@ typedef volatile unsigned int   *dv_reg_p;
 #define KS2_LPSC_GEM_0 15
 #define KS2_LPSC_TETRIS52
 #define KS2_TETRIS_PWR_DOMAIN  31
+#define KS2_GEM_0_PWR_DOMAIN   8
 
 /* Chip configuration unlock codes and registers */
 #define KS2_KICK0  (KS2_DEVICE_STATE_CTRL_BASE + 0x38)
diff --git a/arch/arm/mach-keystone/keystone.c 
b/arch/arm/mach-keystone/keystone.c
index 11a9357db414..a8071270e9bf 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -54,7 +54,7 @@ static void turn_off_all_dsps(int num_dsps)
if (psc_disable_module(i + KS2_LPSC_GEM_0))
printf("Cannot disable module for #%d DSP", i);
 
-   if (psc_disable_domain(i + 8))
+   if (psc_disable_domain(i + KS2_GEM_0_PWR_DOMAIN))
printf("Cannot disable domain for #%d DSP", i);
}
 }
-- 
2.7.0

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

[U-Boot] [PATCH V2 3/6] ARM: keystone2: Allow for board specific speed definitions

2016-03-04 Thread Nishanth Menon 
From: Lokesh Vutla 

Its not compulsory that speed definition should be same on EFUSE_BOOTROM
register for all keystone 2 devices. So, allow for board specific
speed definitions.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
Reviewed-by: Tom Rini 
---
Changes in V2:
- Picked up Reviewed by
V1: https://patchwork.ozlabs.org/patch/588159/

 arch/arm/mach-keystone/clock.c  | 12 ++--
 arch/arm/mach-keystone/include/mach/clock.h |  4 ++--
 board/ti/ks2_evm/board_k2e.c|  2 +-
 board/ti/ks2_evm/board_k2hk.c   |  4 ++--
 board/ti/ks2_evm/board_k2l.c|  4 ++--
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-keystone/clock.c b/arch/arm/mach-keystone/clock.c
index 5c6051e76db8..1ae3baf982a1 100644
--- a/arch/arm/mach-keystone/clock.c
+++ b/arch/arm/mach-keystone/clock.c
@@ -228,14 +228,14 @@ void init_plls(void)
}
 }
 
-static int get_max_speed(u32 val, u32 speed_supported)
+static int get_max_speed(u32 val, u32 speed_supported, int *spds)
 {
int speed;
 
/* Left most setbit gives the speed */
for (speed = DEVSPEED_NUMSPDS; speed >= 0; speed--) {
if ((val & BIT(speed)) & speed_supported)
-   return speeds[speed];
+   return spds[speed];
}
 
/* If no bit is set, use SPD800 */
@@ -250,24 +250,24 @@ static inline u32 read_efuse_bootrom(void)
return __raw_readl(KS2_EFUSE_BOOTROM);
 }
 
-int get_max_arm_speed(void)
+int get_max_arm_speed(int *spds)
 {
u32 armspeed = read_efuse_bootrom();
 
armspeed = (armspeed & DEVSPEED_ARMSPEED_MASK) >>
DEVSPEED_ARMSPEED_SHIFT;
 
-   return get_max_speed(armspeed, ARM_SUPPORTED_SPEEDS);
+   return get_max_speed(armspeed, ARM_SUPPORTED_SPEEDS, spds);
 }
 
-int get_max_dev_speed(void)
+int get_max_dev_speed(int *spds)
 {
u32 devspeed = read_efuse_bootrom();
 
devspeed = (devspeed & DEVSPEED_DEVSPEED_MASK) >>
DEVSPEED_DEVSPEED_SHIFT;
 
-   return get_max_speed(devspeed, DEV_SUPPORTED_SPEEDS);
+   return get_max_speed(devspeed, DEV_SUPPORTED_SPEEDS, spds);
 }
 
 /**
diff --git a/arch/arm/mach-keystone/include/mach/clock.h 
b/arch/arm/mach-keystone/include/mach/clock.h
index cdcff3baee36..dfebcb03ea57 100644
--- a/arch/arm/mach-keystone/include/mach/clock.h
+++ b/arch/arm/mach-keystone/include/mach/clock.h
@@ -124,8 +124,8 @@ struct pll_init_data *get_pll_init_data(int pll);
 unsigned long clk_get_rate(unsigned int clk);
 unsigned long clk_round_rate(unsigned int clk, unsigned long hz);
 int clk_set_rate(unsigned int clk, unsigned long hz);
-int get_max_dev_speed(void);
-int get_max_arm_speed(void);
+int get_max_dev_speed(int *spds);
+int get_max_arm_speed(int *spds);
 void pll_pa_clk_sel(void);
 
 #endif
diff --git a/board/ti/ks2_evm/board_k2e.c b/board/ti/ks2_evm/board_k2e.c
index f58f62358d3e..cbb3077bc36c 100644
--- a/board/ti/ks2_evm/board_k2e.c
+++ b/board/ti/ks2_evm/board_k2e.c
@@ -61,7 +61,7 @@ struct pll_init_data *get_pll_init_data(int pll)
 
switch (pll) {
case MAIN_PLL:
-   speed = get_max_dev_speed();
+   speed = get_max_dev_speed(speeds);
data = _pll_config[speed];
break;
case PASS_PLL:
diff --git a/board/ti/ks2_evm/board_k2hk.c b/board/ti/ks2_evm/board_k2hk.c
index 0bd6b86e2573..e217beaed5e4 100644
--- a/board/ti/ks2_evm/board_k2hk.c
+++ b/board/ti/ks2_evm/board_k2hk.c
@@ -51,11 +51,11 @@ struct pll_init_data *get_pll_init_data(int pll)
 
switch (pll) {
case MAIN_PLL:
-   speed = get_max_dev_speed();
+   speed = get_max_dev_speed(speeds);
data = _pll_config[speed];
break;
case TETRIS_PLL:
-   speed = get_max_arm_speed();
+   speed = get_max_arm_speed(speeds);
data = _pll_config[speed];
break;
case PASS_PLL:
diff --git a/board/ti/ks2_evm/board_k2l.c b/board/ti/ks2_evm/board_k2l.c
index d750ad3c0b05..2a2e0057e24e 100644
--- a/board/ti/ks2_evm/board_k2l.c
+++ b/board/ti/ks2_evm/board_k2l.c
@@ -50,11 +50,11 @@ struct pll_init_data *get_pll_init_data(int pll)
 
switch (pll) {
case MAIN_PLL:
-   speed = get_max_dev_speed();
+   speed = get_max_dev_speed(speeds);
data = _pll_config[speed];
break;
case TETRIS_PLL:
-   speed = get_max_arm_speed();
+   speed = get_max_arm_speed(speeds);
data = _pll_config[speed];
break;
case PASS_PLL:
-- 
2.7.0

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

2016-03-04 Thread Dinh Nguyen 
On 03/02/2016 05:24 PM, Marek Vasut wrote:
> On 03/03/2016 12:08 AM, Dinh Nguyen wrote:
>> On 03/02/2016 04:54 PM, Dinh Nguyen wrote:
>>> CC: Marek Vasut
>>>
>>> On 03/01/2016 08:40 PM, George Broz wrote:
 On 17 February 2016 at 18:45, Phil Reid  wrote:
> G'day George
>
>
> On 18/02/2016 5:54 AM, George Broz wrote:
>>
>> Hello,
>>
>> Sorry for the newbie question...
>>
>> I have an Altera/Terasic board (socfpga_sockit) that has issues
>> recognizing
>> USB storage devices (roughly 60% good / 40% bad):
>>

>> If I try a later release (e.g. v2016.01 which seems to support the 
>> Terasic
>> board explicitly) the boot process stops just after loading the SPL.
>>
>> At this point I have only been changing the u-boot.img component, not the
>> SPL (in the a2 partition of the MMC).
>>
>> The documentation from Altera about generating the SPL seems to require
>> using Qsys/Quartus tools which I'd really like to avoid.
>>
>> I can produce u-boot-spl.bin / u-boot.img from
>> make socfpga_sockit_defconfig; make all.
>>
>> My newbie question ... should be I able to use directly the 
>> u-boot-spl.bin
>> generated by the build to replace the SPL on the board?
>>
>
> I've just gone thru the process (this week) of getting uboot 2016.01 to 
> boot
> on our custom socfpga board.
> There where a few issues in getting things going.
> If your using the sd card to boot then the current memory layout is not 
> per
> the altera documentation.
> I had to make the changes below to config to match the altera docs.
> Otherwise it hangs just after the SPL.
> You also need to use the -dtb image versions with 2016.01 for things to
> work.
> Again you may need to make sure the uboot device trees match your 
> hardware.
> Not all uboot drivers appear to be using the DT as yet.
>
> Note the SPL is tightly coupled to the board design and potentially the 
> FPGA
> image.
> If you using bridges or routing HPS resources (eg i2c etc) to the fpga the
> SPL configures the muxes.
>
> There's a script in uboot src at arch\arm\mach-socfpga\qts-filter.sh
> That will generate the qts files for you arch.
>
> I haven't tried the USB stuff as yet.
> There are some issues witht eh altera USB port trigger an Over Current 
> event
> on device insertation.
> They've modified the linux kenerl driver to use external OV current
> detection to get around the problem.
> My intial workaround was to insert USB device prior to power on.
> I haven't looked at the uboot USB driver yet to see what's in there.
>
>
> --
> Regards
> Phil Reid
>
>
> diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> index a09e906..3a1b59b 100644 (file)
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -357,13 +357,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>
> /* SPL SDMMC boot support */
> #ifdef CONFIG_SPL_MMC_SUPPORT
> +#define CONFIG_SPL_LIBDISK_SUPPORT
> #if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
> #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 2
> #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"
> -#define CONFIG_SPL_LIBDISK_SUPPORT
> #else
> -#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 3
> -#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0xa00 /* offset 2560 sect
> (1M+256k) */
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 3
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200
> #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
> #endif
> #endif
>
>

 Thanks, Phil!

 Sorry for the delayed response - got called away, but am back to this
 now. I patched
 socfpga_common.h and re-built the project. I picked up
 spl/u-boot-spl-dtb.sfp and
 u-boot-dtb.img and transferred them to the SD card with:

 dd if=u-boot-spl-dtb.sfp of=/dev/sdf3 bs=64k seek=0
 dd if=u-boot-dtb.img of=/dev/sdf3 bs=64k seek=4

>>>
>>> You can just do a 'make u-boot-with-spl.sfp' and burn the
>>> u-boot-with-spl.sfp file straight to the a2 partition, or sdf3.
>>>
 Tried this with both the original DT set (socfpga.dtsi, 
 socfpga_cyclone.dtsi,
 socfpga_cyclone5_sockit.dts) that came with the u-boot v2016.01 download 
 and
 also an Altera-patched DT set that I've used to boot into Linux numerous 
 times.

 When I start up the board I get:

 U-Boot SPL 2016.01 (Mar 01 2016 - 17:28:14)
 drivers/ddr/altera/sequencer.c: Preparing to start memory calibration
 drivers/ddr/altera/sequencer.c: CALIBRATION FAILED
 drivers/ddr/altera/sequencer.c: Calibration complete
 SDRAM calibration

Re: [U-Boot] [PATCH v2 2/2] warp7: Add initial support

2016-03-04 Thread Fabio Estevam 
On Fri, Mar 4, 2016 at 11:22 AM, Stefano Babic  wrote:

> Really I have postponed to -next. As we have now two month cycle
> release, the merge window becomes more strictly and I will try to not
> let flow patches that are not fixes after window is closed.

It makes sense. Just wanted to confirm, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] warp7: Add initial support

2016-03-04 Thread Stefano Babic 
Hi Fabio,

On 04/03/2016 14:11, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Feb 29, 2016 at 9:33 AM, Fabio Estevam  wrote:
>> From: Fabio Estevam 
>>
>> Add the basic support for Warp7 board.
>>
>> For more information about this reference design, please visit:
>>
>> https://www.element14.com/community/docs/DOC-79058/l/warp-7-the-next-generation-wearable-reference-platform
>>
>> Signed-off-by: Fabio Estevam 
>> Reviewed-by: Peng Fan 
> 
> Do you think we could get the support for this new board into 2016.03?

Really I have postponed to -next. As we have now two month cycle
release, the merge window becomes more strictly and I will try to not
let flow patches that are not fixes after window is closed.

Regards,
Stefano

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

Re: [U-Boot] [PATCH v2 2/2] warp7: Add initial support

2016-03-04 Thread Fabio Estevam 
Hi Stefano,

On Mon, Feb 29, 2016 at 9:33 AM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> Add the basic support for Warp7 board.
>
> For more information about this reference design, please visit:
>
> https://www.element14.com/community/docs/DOC-79058/l/warp-7-the-next-generation-wearable-reference-platform
>
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Peng Fan 

Do you think we could get the support for this new board into 2016.03?

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

Re: [U-Boot] Ethernet not found on Arria 5.

2016-03-04 Thread Bakhvalov, Denis (Nokia - PL/Wroclaw) 
Hi,

> It seems like your PHY is not recongnised. Could there be some reset
> line which is left asserted ?

I'm afraid I don't know how to check that.

But I have previous version of U-Boot (2013) where Ethernet is working.
Maybe I can check it there?
I already tried to go that path, but code is quite different there.

With U-Boot 2013 it is enough to config fpga and set env variables to have ping 
in both directions.

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Ethernet not found on Arria 5.

2016-03-04 Thread Marek Vasut 
On 03/04/2016 10:20 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Dear U-Boot support,
> 
> I'm migrating to new U-Boot version from 2013 and now have Ethernet
> not working both in U-Boot and in Linux (after booting).
> 
> I have custom board with Altera Arria 5 SocFpga onboard. U-Boot
> version: 2016.03-rc1
> 
> In logs I can see:
> 
> Net:   No ethernet found.
> 
> With more verbose:
> 
> designware_eth_probe, iobase=ff702000, priv=1eb286a0 
> ethernet@ff702000 PHY: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
> 19 20 21 22 23 24 25 26 27 28 29 30 31 not found 
> designware_eth_probe, ret=-19 No ethernet found.
> 
> Ethernet connection inside my board is following: [CPU] - [EMAC1]
> - [ FPGA ]  [ PHY(KSZ8081MNXIA) ]
> 
> I already tried to configure FPGA from Linux environment but it
> didn't solved the problem. My U-Boot configuration was cloned from
> socfpga dev kit board with some modifications. But Ethernet
> configuration I didn't touched yet.
> 
> So far I tried to debug it with no success. Also I played with env
> variables (ethact, ethaddr) and CONFIG_PHY_ADDR with no success as
> well. Something tells me that I have incorrect EMAC configuration but
> I don't know how to tackle it.
> 
> Please help me identify the problem or at least give me some hints
> where to look to solve my issue.

It seems like your PHY is not recongnised. Could there be some reset
line which is left asserted ?

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

Re: [U-Boot] Problem with attaching UBI partition

2016-03-04 Thread Marek Vasut 
On 03/04/2016 01:24 PM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>>> Currently I have Ethernet not working :(  
>>
>> OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.
> 
> Yes. I didn't changed that.
> It is gmac1: ethernet@ff702000.
> 
> I already started new topic for that problem here:
> http://lists.denx.de/pipermail/u-boot/2016-March/247290.html
> Let's continue discussion there. :)

OK

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

Re: [U-Boot] Problem with attaching UBI partition

2016-03-04 Thread Bakhvalov, Denis (Nokia - PL/Wroclaw) 
Hi Marek,

> > Currently I have Ethernet not working :(  
>
> OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

Yes. I didn't changed that.
It is gmac1: ethernet@ff702000.

I already started new topic for that problem here:
http://lists.denx.de/pipermail/u-boot/2016-March/247290.html
Let's continue discussion there. :)

Best regards,
Denis Bakhvalov

MBB Radio Platforms, RFSW


-Original Message-
From: EXT Marek Vasut [mailto:ma...@denx.de] 
Sent: Friday, March 04, 2016 13:20
To: Bakhvalov, Denis (Nokia - PL/Wroclaw) ; EXT 
Jagan Teki 
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Problem with attaching UBI partition

On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>> It's I belive in socfpga_common.h and it should be migrated to
>> socfpga_*_defconfig where it makes sense. Do you want to submit
>> a patch for this ?
> 
> I put it in my todo list.
> Once I will finish with u-boot bringup I will submit the patch.
> Currently I have Ethernet not working :(  

OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

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

Re: [U-Boot] Problem with attaching UBI partition

2016-03-04 Thread Marek Vasut 
On 03/04/2016 10:03 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote:
> Hi Marek,

Hi,

>> It's I belive in socfpga_common.h and it should be migrated to
>> socfpga_*_defconfig where it makes sense. Do you want to submit
>> a patch for this ?
> 
> I put it in my todo list.
> Once I will finish with u-boot bringup I will submit the patch.
> Currently I have Ethernet not working :(  

OK. Do you use the same ethernet controller as ArriaV SoCDK? There are two.

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

Re: [U-Boot] [PATCH] efi_loader: Reserve 2 additional pages for fdt

2016-03-04 Thread Leif Lindholm 
On Fri, Mar 04, 2016 at 10:19:10AM +0100, Alexander Graf wrote:
> We mark the device tree as reserved today, spanning exactly the amount
> of space it needs. If some other piece of code (like grub2) comes in and
> wants to modify the device tree to for example add a kernel command line
> though, it might assume that it has some space to do so.
> 
> So let's just reserve 2 additional pages for the device tree to play nicely.

I presume this was triggered by something you found on AArch32 grub,
booting a kernel without EFI stub?
If so, the issue will go away once I fix the AArch32 grub to use the
AArch64 loader for kernel images with the EFI stub. Could you possibly
send an email to grub-devel, or raise a ticket directly on the
savannah bugtracker if you have an account?
This fix really should go into 2.02 release.

Regardless, this seems like it provides a potential optimisation
opportunity for such agents, to use the tree in place instead of
always allocating more memory.

> Signed-off-by: Alexander Graf 
> ---
>  cmd/bootefi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index de17e49..faa6978 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -119,6 +119,8 @@ static unsigned long do_bootefi_exec(void *efi)
>   fdt_end = ((ulong)working_fdt) + fdt_totalsize(working_fdt);
>   fdt_size = (fdt_end - fdt_start) + EFI_PAGE_MASK;
>   fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
> + /* Give a bootloader the chance to modify the device tree */
> + fdt_pages += 2;
>   efi_add_memory_map(fdt_start, fdt_pages,
>  EFI_BOOT_SERVICES_DATA, true);
>  
> -- 
> 1.8.5.6
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Ethernet not found on Arria 5.

2016-03-04 Thread Bakhvalov, Denis (Nokia - PL/Wroclaw) 
Dear U-Boot support,

I'm migrating to new U-Boot version from 2013 and now have Ethernet not working 
both in U-Boot and in Linux (after booting).

I have custom board with Altera Arria 5 SocFpga onboard.
U-Boot version: 2016.03-rc1

In logs I can see:

 Net:   No ethernet found.

With more verbose:

 designware_eth_probe, iobase=ff702000, priv=1eb286a0
 ethernet@ff702000 PHY: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30 31 not found
 designware_eth_probe, ret=-19
 No ethernet found.

Ethernet connection inside my board is following:
   [CPU] - [EMAC1] - [ FPGA ]  [ PHY(KSZ8081MNXIA) ]

I already tried to configure FPGA from Linux environment but it didn't solved 
the problem.
My U-Boot configuration was cloned from socfpga dev kit board with some 
modifications.
But Ethernet configuration I didn't touched yet.

So far I tried to debug it with no success. Also I played with env variables 
(ethact, ethaddr) and CONFIG_PHY_ADDR with no success as well.
Something tells me that I have incorrect EMAC configuration but I don't know 
how to tackle it.

Please help me identify the problem or at least give me some hints where to 
look to solve my issue.

Best regards,
Denis Bakhvalov

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

[U-Boot] [PATCH] efi_loader: Reserve 2 additional pages for fdt

2016-03-04 Thread Alexander Graf 
We mark the device tree as reserved today, spanning exactly the amount
of space it needs. If some other piece of code (like grub2) comes in and
wants to modify the device tree to for example add a kernel command line
though, it might assume that it has some space to do so.

So let's just reserve 2 additional pages for the device tree to play nicely.

Signed-off-by: Alexander Graf 
---
 cmd/bootefi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index de17e49..faa6978 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -119,6 +119,8 @@ static unsigned long do_bootefi_exec(void *efi)
fdt_end = ((ulong)working_fdt) + fdt_totalsize(working_fdt);
fdt_size = (fdt_end - fdt_start) + EFI_PAGE_MASK;
fdt_pages = fdt_size >> EFI_PAGE_SHIFT;
+   /* Give a bootloader the chance to modify the device tree */
+   fdt_pages += 2;
efi_add_memory_map(fdt_start, fdt_pages,
   EFI_BOOT_SERVICES_DATA, true);
 
-- 
1.8.5.6

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

Re: [U-Boot] Problem with attaching UBI partition

2016-03-04 Thread Bakhvalov, Denis (Nokia - PL/Wroclaw) 
Hi Marek,

> It's I belive in socfpga_common.h and it should be migrated to
> socfpga_*_defconfig where it makes sense. Do you want to submit
> a patch for this ?

I put it in my todo list.
Once I will finish with u-boot bringup I will submit the patch.
Currently I have Ethernet not working :(  

Best regards,
Denis Bakhvalov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] malloc: handle free() before gd is set

2016-03-04 Thread Hans de Goede 

Hi,

On 04-03-16 09:19, Stephen Warren wrote:

On at least Ubuntu Xenial, free() can be called before main(). In this
case, U-Boot won't have set gd, so dereferencing it will crash. Check
whether gd is set before using it.

While at it, apply the same fix to other functions.

Signed-off-by: Stephen Warren 
---
  common/dlmalloc.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 5ea37dfb6e4c..7453e63d6bf4 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -2453,7 +2453,7 @@ void fREe(mem) Void_t* mem;

  #ifdef CONFIG_SYS_MALLOC_F_LEN
/* free() is a no-op - all the memory will be freed on relocation */
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
return;
  #endif



I believe you want:

+   if (!gd || !(gd->flags & GD_FLG_FULL_MALLOC_INIT))

Instead, so that you actually go into the return; path when there is no gd.

Regards,

Hans




@@ -2609,7 +2609,7 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t 
bytes;
if (oldmem == NULL) return mALLOc(bytes);

  #ifdef CONFIG_SYS_MALLOC_F_LEN
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
/* This is harder to support and should not be needed */
panic("pre-reloc realloc() is not supported");
}
@@ -2985,7 +2985,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
else
{
  #ifdef CONFIG_SYS_MALLOC_F_LEN
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
MALLOC_ZERO(mem, sz);
return mem;
}


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

[U-Boot] [PATCH] malloc: handle free() before gd is set

2016-03-04 Thread Stephen Warren 
On at least Ubuntu Xenial, free() can be called before main(). In this
case, U-Boot won't have set gd, so dereferencing it will crash. Check
whether gd is set before using it.

While at it, apply the same fix to other functions.

Signed-off-by: Stephen Warren 
---
 common/dlmalloc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 5ea37dfb6e4c..7453e63d6bf4 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -2453,7 +2453,7 @@ void fREe(mem) Void_t* mem;
 
 #ifdef CONFIG_SYS_MALLOC_F_LEN
/* free() is a no-op - all the memory will be freed on relocation */
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
return;
 #endif
 
@@ -2609,7 +2609,7 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t 
bytes;
   if (oldmem == NULL) return mALLOc(bytes);
 
 #ifdef CONFIG_SYS_MALLOC_F_LEN
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
/* This is harder to support and should not be needed */
panic("pre-reloc realloc() is not supported");
}
@@ -2985,7 +2985,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
   else
   {
 #ifdef CONFIG_SYS_MALLOC_F_LEN
-   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
+   if (gd && !(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
MALLOC_ZERO(mem, sz);
return mem;
}
-- 
2.7.0

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