Re: [U-Boot] [PATCH 10/10] x86: Add Intel Cougar Canyon 2 board

[Bin Meng]

Hi Simon,

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> This adds basic support to Intel Cougar Canyon 2 board, a board
>> based on Chief River platform with an Ivy Bridge processor and
>> a Panther Point chipset.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>>  arch/x86/dts/Makefile |  1 +
>>  arch/x86/dts/cougarcanyon2.dts| 96 
>> +++
>>  board/intel/Kconfig   |  9 +++
>>  board/intel/cougarcanyon2/Kconfig | 25 
>>  board/intel/cougarcanyon2/MAINTAINERS |  6 ++
>>  board/intel/cougarcanyon2/Makefile|  7 +++
>>  board/intel/cougarcanyon2/cougarcanyon2.c | 48 
>>  board/intel/cougarcanyon2/start.S |  9 +++
>>  configs/cougarcanyon2_defconfig   | 21 +++
>>  include/configs/cougarcanyon2.h   | 34 +++
>>  10 files changed, 256 insertions(+)
>>  create mode 100644 arch/x86/dts/cougarcanyon2.dts
>>  create mode 100644 board/intel/cougarcanyon2/Kconfig
>>  create mode 100644 board/intel/cougarcanyon2/MAINTAINERS
>>  create mode 100644 board/intel/cougarcanyon2/Makefile
>>  create mode 100644 board/intel/cougarcanyon2/cougarcanyon2.c
>>  create mode 100644 board/intel/cougarcanyon2/start.S
>>  create mode 100644 configs/cougarcanyon2_defconfig
>>  create mode 100644 include/configs/cougarcanyon2.h
>
> Acked-by: Simon Glass 
>
> A few nits though:
> - Include order -  - can we drop the calls to x86_pci_...? Please check it on top of the
> u-boot-dm/pcif-working series
>

Yep, I plan to do v2 after all your previous DM patches are applied.

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

Re: [U-Boot] [PATCH 3/8] spi: Rename SPI_OPM_RX_* to SPI_RX_*

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> SPI_OPM_RX_AS   - SPI_RX_SLOW
> SPI_OPM_RX_AF   - SPI_RX_FAST
> SPI_OPM_RX_DOUT - SPI_RX_DUAL
> SPI_OPM_RX_QOF  - SPI_RX_QUAD
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH 4/8] spi: Rename op_mode_rx to mode_rx

[Bin Meng]

Hi Jagan,

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> Since spi rx mode macro's are renamed to simple and
> meaninfull in below patch, this patch will rename
> the respective structure member.
> "spi: Rename SPI_OPM_RX_* to SPI_RX_*"
> (sha1: 5e9ffbc5376616449beaaf2bc100f579f12291cf)

I don't see this commit id in the origin/master. Can you please double check?

>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

Other than that,

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 

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

Re: [U-Boot] [PATCH 6/8] spi: Fix bit assignment with flags

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> Fixed bit assignment with flags members on spi_slave{}
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH 8/8] spi: Minor cleanup

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> - Add comments on mode_rx
> - Tab space's
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH 7/8] spi: Use BIT macro

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> Used BIT macro like 1 << nr as BIT(nr) where nr is 0...n
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH 2/8] spi: Remove SPI_OPM_RX_DIO|QIOF

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> SPI_OPM_RX_DIO and SPI_OPM_RX_QIOF are rx IO
> commands/opmodes for dual and quad. Usually IO
> operation's are referred to flash protocol rather
> with spi controller protocol, these are still present
> in flash side for the usage of spi-nor controllers.
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

[U-Boot] [PATCH] ARM: dts: uniphier: add SD/MMC pinmux nodes

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-pinctrl.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/dts/uniphier-pinctrl.dtsi 
b/arch/arm/dts/uniphier-pinctrl.dtsi
index b584213..b1691d0 100644
--- a/arch/arm/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/dts/uniphier-pinctrl.dtsi
@@ -7,6 +7,11 @@
  */
 
  {
+   pinctrl_emmc: emmc_grp {
+   groups = "emmc", "emmc_dat8";
+   function = "emmc";
+   };
+
pinctrl_i2c0: i2c0_grp {
groups = "i2c0";
function = "i2c0";
@@ -27,6 +32,16 @@
function = "i2c3";
};
 
+   pinctrl_sd: sd_grp {
+   groups = "sd";
+   function = "sd";
+   };
+
+   pinctrl_sd1: sd1_grp {
+   groups = "sd1";
+   function = "sd1";
+   };
+
pinctrl_uart0: uart0_grp {
groups = "uart0";
function = "uart0";
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/2] Rockchip: USB: added usb phy control to support fastboot

[Tom Rini]

On Sat, Dec 19, 2015 at 11:57:26PM +0100, Marek Vasut wrote:
> On Saturday, December 19, 2015 at 11:25:12 PM, Simon Glass wrote:
> > Hi Marek,
> > 
> > On 19 December 2015 at 14:23, Marek Vasut  wrote:
> > > On Saturday, December 19, 2015 at 09:30:09 PM, Simon Glass wrote:
> > >> Hi Frank,
> > >> 
> > >> On 4 December 2015 at 11:28, Marek Vasut  wrote:
> > >> > On Friday, December 04, 2015 at 10:36:32 AM, Frank Wang wrote:
> > >> >> This series adds support for fastboot related to USB.
> > >> >> 
> > >> >> [PATCH 1/2] fixed max packet size check error for ep_in in high speed
> > >> >> condition
> > >> >> 
> > >> >> [PATCH 2/2] add usb phy control to support fastboot for rk3036
> > >> >> 
> > >> >> Tested on RK3036 SDK board, it works Okay.
> > >> > 
> > >> > I submitted a series [1] about a day ago which renames the s3c driver
> > >> > to dwc2. You should update your series based on that. To make things
> > >> > easier, just wait a bit until this lands in u-boot-usb .
> > >> > 
> > >> > Sorry for the hassle.
> > >> > 
> > >> > [1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/243401
> > >> 
> > >> Are you planning to respin this series? I'd like to apply it for -next.
> > > 
> > > Are you now picking USB patches too ? ;-) S3C was recently renamed it
> > > dwc2, so you might want to respin the series anyway. In this case, it's
> > > a simple matter of s/s3c/dwc2/g .
> > 
> > Not really, it is just that it appeared in my patchwork queue. I'm
> > happy for you to pick it up.
> 
> Looks like the patchwork distribution doesn't work quite well ;-)

It works better when everyone looks at it more often, yes ;).  I usually
delegate things that don't look to be "core" but rather "soc" changes to
the SoC custodian in question.

-- 
Tom


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

Re: [U-Boot] [RFC PATCH 01/11] serial: Add support for Qualcomm serial port

[Masahiro Yamada]

2015-12-16 3:58 GMT+09:00 Simon Glass :

>> +++ b/drivers/serial/serial_msm.c
>> @@ -0,0 +1,204 @@
>> +/*
>> + * Qualcomm UART driver
>> + *
>> + * (C) Copyright 2015 Mateusz Kulikowski 
>> + *
>> + * UART will work in Data Mover mode.
>> + * Based on Linux driver.
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Ordering:
>
> common.h
> clk.h
> dm.h
> errno.h
> serial.h
> watchdog.h
> asm/
> linux/
>
>

No.

Put  above , at least.
(the same order in Linux)



BTW, the "Include file order" in
http://www.denx.de/wiki/U-Boot/CodingStyle

Is this your opinion? Or community's opinion.

Did anybody review it?




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

Re: [U-Boot] [PATCH 07/10] x86: fsp: Make sure HOB list is not overwritten by U-Boot

[Bin Meng]

Hi Simon,

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> Intel IvyBridge FSP seems to be buggy that it does not report memory
>> used by FSP itself as reserved in the resource descriptor HOB. The
>> FSP specification does not describe how resource descriptor HOBs are
>> generated by the FSP to describe what memory regions. It looks newer
>> FSPs like Queensbay and BayTrail do not have such issue. This causes
>> U-Boot relocation overwrites the important boot service data which is
>> used by FSP, and the subsequent call to fsp_notify() will fail.
>>
>> To resolve this, we find out the lowest memory base address allocated
>> by FSP for the boot service data when walking through the HOB list in
>> fsp_get_usable_lowmem_top(). Check whether the memory top address is
>> below the FSP HOB list, and if not, use the lowest memory base address
>> allocated by FSP as the memory top address.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/lib/fsp/fsp_support.c | 27 +++
>>  1 file changed, 27 insertions(+)
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 
>
> But if this is a bug I'd prefer to have it behind an #iffdef, or with
> a large comment in the code. Otherwise we might think it is an
> important feature for all platforms.
>

Yep, will change to use #ifdef in v2.

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

Re: [U-Boot] [PATCH 1/8] spi: Remove SPI_OPM_RX_EXTN

[Bin Meng]

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> SPI_OPM_RX_EXTN is a combination of all rx opmode's
> and spi driver shall use any one of the rx mode at
> a time not the combination and it is true in case of
> flash where spi_flash_table mention combination of
> supported read opmodes so-that the required one
> will pick based on the rx mode from spi driver.
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH] x86: Remove Graeme Russ from the git alias file

[Bin Meng]

On Sun, Dec 20, 2015 at 6:44 AM, Simon Glass  wrote:
> As requested, remove Graeme's email address.
>
> Signed-off-by: Simon Glass 
> ---
>

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

Re: [U-Boot] [PATCH] spi: sf: add support for throughput mesurement of sf read/write

[Mugunthan V N]

On Friday 18 December 2015 11:37 AM, Stefan Roese wrote:
> On 17.12.2015 17:44, Jagan Teki wrote:
>> On 17 December 2015 at 13:26, Mugunthan V N  wrote:
>>> On Thursday 17 December 2015 12:43 PM, Jagan Teki wrote:
 On 17 December 2015 at 12:33, Mugunthan V N 
 wrote:
> Jagan
>
> On Tuesday 27 October 2015 07:24 PM, Mugunthan V N wrote:
>> This patch adds time measurement and throughput calculation for
>> sf read/write commands.
>>
>> The output of sf read changes from
>>
>> ---8<---
>> SF: 4096 bytes @ 0x0 Read: OK
>> --->8---
>>
>> to
>>
>> ---8<---
>> SF: 4096 bytes @ 0x0 Read: OK in 6 ms (666 KiB/s)
>> --->8---
>>
>> Signed-off-by: Mugunthan V N 

 Was it similar to 'sf update' ? please check it once.

>>>
>>> sf update out similar but also uses progressive output, in read/write
>>> case it can't be done. The final throughput measurement is similar on
>>> both update and read/write.
>>
>> True, that's what if we need a progressed throughput just use 'sf
>> update' else normal 'sf read/write' It's look not good to me to add
>> extra code on top of generic commands. What ever we wanted to extend
>> features let's added it on 'sf update' than sf read/write, Sorry.
> 
> If I need to measure the time of commands, I use the "time"
> command ("time sf write ...") by enabling it via CONFIG_CMD_TIME.
> This provides all the needed information to detect performance
> changes.
> 

But similar kind of implementations is present for fatload and tftp. So
I thought having similar performance log for sf read/write will be good
as well.

Regards
Mugunthan V N

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

Re: [U-Boot] [PATCH 5/8] spi: Move mode, mode_rx, flags macro's to structure

[Bin Meng]

Hi Jagan,

On Wed, Dec 16, 2015 at 11:40 PM, Jagan Teki  wrote:
> This patch moves mode, mode_rx, flags macro's to respective
> member position on spi_slave{}, for better readabilty and
> finding the respective member macro's easily.

I am not in favor of mixing macros along with the structure members.
This looks to me not clearer than before. Do we have some guideline
anywhere?

>
> This patch fix's the tab space on mode macro's as well.
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH] spi: sf: add support for throughput mesurement of sf read/write

[Jagan Teki]

Hi Mugunthan,

On 21 December 2015 at 11:30, Stefan Roese  wrote:
> On 21.12.2015 06:37, Mugunthan V N wrote:
>>
>> On Friday 18 December 2015 11:37 AM, Stefan Roese wrote:
>>>
>>> On 17.12.2015 17:44, Jagan Teki wrote:

 On 17 December 2015 at 13:26, Mugunthan V N  wrote:
>
> On Thursday 17 December 2015 12:43 PM, Jagan Teki wrote:
>>
>> On 17 December 2015 at 12:33, Mugunthan V N 
>> wrote:
>>>
>>> Jagan
>>>
>>> On Tuesday 27 October 2015 07:24 PM, Mugunthan V N wrote:

 This patch adds time measurement and throughput calculation for
 sf read/write commands.

 The output of sf read changes from

 ---8<---
 SF: 4096 bytes @ 0x0 Read: OK
 --->8---

 to

 ---8<---
 SF: 4096 bytes @ 0x0 Read: OK in 6 ms (666 KiB/s)
 --->8---

 Signed-off-by: Mugunthan V N 
>>
>>
>> Was it similar to 'sf update' ? please check it once.
>>
>
> sf update out similar but also uses progressive output, in read/write
> case it can't be done. The final throughput measurement is similar on
> both update and read/write.


 True, that's what if we need a progressed throughput just use 'sf
 update' else normal 'sf read/write' It's look not good to me to add
 extra code on top of generic commands. What ever we wanted to extend
 features let's added it on 'sf update' than sf read/write, Sorry.
>>>
>>>
>>> If I need to measure the time of commands, I use the "time"
>>> command ("time sf write ...") by enabling it via CONFIG_CMD_TIME.
>>> This provides all the needed information to detect performance
>>> changes.
>>>
>>
>> But similar kind of implementations is present for fatload and tftp. So
>> I thought having similar performance log for sf read/write will be good
>> as well.
>
>
> Yes, I understand. I also find this output helpful. But I'm not sure,
> if we should add this timing code to all these functions. Instead
> of just using this common time command, if needed. To keep the
> code size at a minimum.
>
> Of course its no big code addition, so I don't really have any bigger
> reservations against it.

Why can't just use 'sf update' instead of adding again same code in
'sf read/write' since 'sf update' is doing more than just giving
timing performance. Please try!

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

Re: [U-Boot] [PATCH v1 01/18] MIPS: Prepare device-tree support.

[Purna Chandra Mandal]

On 12/20/2015 03:52 AM, Daniel Schwierzeck wrote:

>
> Am 17.12.2015 um 18:28 schrieb Purna Chandra Mandal:
>> Signed-off-by: Purna Chandra Mandal 
> if you send patches from other people, you should not remove their
> Author or Signed-off-by. I already prepared a cleaned up version of that
> patch some days ago for submission. But I see you did some modifications
> which I missed. I will add those to my patch and you can drop this one
> in your next patch series. You should rebase your patches against the
> next branch in u-boot-mips tree [1]
>
> [1] http://git.denx.de/?p=u-boot/u-boot-mips.git;a=summary

ack. I'll drop in next version.

>> ---
>>
>>  arch/Kconfig  |  1 +
>>  arch/mips/config.mk   |  3 +++
>>  arch/mips/dts/.gitignore  |  1 +
>>  arch/mips/dts/Makefile| 16 
>>  arch/mips/dts/include/dt-bindings |  1 +
>>  arch/mips/dts/skeleton.dtsi   | 21 +
>>  dts/Makefile  |  2 +-
>>  7 files changed, 44 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/mips/dts/.gitignore
>>  create mode 100644 arch/mips/dts/Makefile
>>  create mode 12 arch/mips/dts/include/dt-bindings
>>  create mode 100644 arch/mips/dts/skeleton.dtsi
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 6489cc9..589fc47 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -54,6 +54,7 @@ config MIPS
>>  select HAVE_PRIVATE_LIBGCC
>>  select HAVE_GENERIC_BOARD
>>  select SYS_GENERIC_BOARD
>> +select SUPPORT_OF_CONTROL
>>  
>>  config NDS32
>>  bool "NDS32 architecture"
>> diff --git a/arch/mips/config.mk b/arch/mips/config.mk
>> index 52e28f2..d4d688e 100644
>> --- a/arch/mips/config.mk
>> +++ b/arch/mips/config.mk
>> @@ -70,3 +70,6 @@ PLATFORM_RELFLAGS+= -ffunction-sections 
>> -fdata-sections
>>  LDFLAGS_FINAL+= --gc-sections -pie
>>  OBJCOPYFLAGS+= -j .text -j .rodata -j .data -j .got
>>  OBJCOPYFLAGS+= -j .u_boot_list -j .rel.dyn -j .padding
>> +ifdef CONFIG_OF_EMBED
>> +OBJCOPYFLAGS+= -j .dtb.init.rodata
>> +endif
>> diff --git a/arch/mips/dts/.gitignore b/arch/mips/dts/.gitignore
>> new file mode 100644
>> index 000..b60ed20
>> --- /dev/null
>> +++ b/arch/mips/dts/.gitignore
>> @@ -0,0 +1 @@
>> +*.dtb
>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
>> new file mode 100644
>> index 000..724b5d2
>> --- /dev/null
>> +++ b/arch/mips/dts/Makefile
>> @@ -0,0 +1,16 @@
>> +#
>> +# SPDX-License-Identifier:GPL-2.0+
>> +#
>> +
>> +#dtb-$(CONFIG_XXX) += xxx.dtb
>> +
>> +targets += $(dtb-y)
>> +
>> +# Add any required device tree compiler flags here
>> +DTC_FLAGS +=
>> +
>> +PHONY += dtbs
>> +dtbs: $(addprefix $(obj)/, $(dtb-y))
>> +@:
>> +
>> +clean-files := *.dtb
>> diff --git a/arch/mips/dts/include/dt-bindings 
>> b/arch/mips/dts/include/dt-bindings
>> new file mode 12
>> index 000..0cecb3d
>> --- /dev/null
>> +++ b/arch/mips/dts/include/dt-bindings
>> @@ -0,0 +1 @@
>> +../../../../include/dt-bindings
>> \ No newline at end of file
>> diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
>> new file mode 100644
>> index 000..ad41546
>> --- /dev/null
>> +++ b/arch/mips/dts/skeleton.dtsi
>> @@ -0,0 +1,21 @@
>> +/*
>> + * Skeleton device tree; the bare minimum needed to boot; just include and
>> + * add a compatible value.  The bootloader will typically populate the 
>> memory
>> + * node.
>> + */
>> +
>> +/ {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +chosen {
>> +};
>> +
>> +aliases {
>> +};
>> +
>> +memory {
>> +device_type = "memory";
>> +reg = <0 0>;
>> +};
>> +};
>> diff --git a/dts/Makefile b/dts/Makefile
>> index d3122aa..5c3a01f 100644
>> --- a/dts/Makefile
>> +++ b/dts/Makefile
>> @@ -45,4 +45,4 @@ dtbs: $(obj)/dt.dtb
>>  clean-files := dt.dtb.S
>>  
>>  # Let clean descend into dts directories
>> -subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/sandbox/dts 
>> ../arch/x86/dts
>> +subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/sandbox/dts 
>> ../arch/x86/dts ../arch/mips/dts
>>

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

[U-Boot] [PATCH] board: m5253demo, fix gcc-5.2.0 compilation warnings

[Angelo Dureghello]

Fix gcc-5.2.0 buildman warnings:
warning: 'w' is static but declared in inline function 'spin_wheel'
which is not static
warning: 'p' is static but declared in inline function 'spin_wheel'
which is not static

Signed-off-by: Angelo Dureghello 

---

 board/freescale/m5253demo/flash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/m5253demo/flash.c 
b/board/freescale/m5253demo/flash.c
index 071701d..099deca 100644
--- a/board/freescale/m5253demo/flash.c
+++ b/board/freescale/m5253demo/flash.c
@@ -31,7 +31,7 @@ typedef volatile unsigned short FLASH_PORT_WIDTHV;
 ulong flash_get_size(FPWV * addr, flash_info_t * info);
 int flash_get_offsets(ulong base, flash_info_t * info);
 int write_word(flash_info_t * info, FPWV * dest, u16 data);
-void inline spin_wheel(void);
+static inline void spin_wheel(void);
 
 flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
 
@@ -439,7 +439,7 @@ int write_word(flash_info_t * info, FPWV * dest, u16 data)
return (res);
 }
 
-void inline spin_wheel(void)
+static inline void spin_wheel(void)
 {
static int p = 0;
static char w[] = "\\/-";
-- 
2.5.3


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

Re: [U-Boot] [PATCH] net: designware: Zap CONFIG_DW_AUTONEG

[Bin Meng]

On Sun, Dec 20, 2015 at 10:59 AM, Marek Vasut  wrote:
> This symbol is not used anywhere, so remove it. For spear600, remove
> it from the board file, since the symbol is not defined for spear600
> either.
>
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Joe Hershberger 
> ---

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

Re: [U-Boot] [PATCH] net: designware: Zap trailing backslash

[Bin Meng]

On Sun, Dec 20, 2015 at 10:59 AM, Marek Vasut  wrote:
> Trailing backslashes are necessary only in macros, not in the actual
> code, so remove them.
>
> Signed-off-by: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Joe Hershberger 
> ---

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

Re: [U-Boot] [PATCH 02/10] x86: ivybridge: Add FSP support

[Bin Meng]

Hi Simon,

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> IvyBridge FSP package is built with a base address at 0xfff8,
>> and does not use UPD data region. This adds basic FSP support.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/ivybridge/Kconfig |  8 
>>  arch/x86/cpu/ivybridge/Makefile|  4 ++
>>  arch/x86/cpu/ivybridge/fsp_configs.c   | 45 
>> ++
>>  arch/x86/cpu/ivybridge/ivybridge.c | 22 +++
>>  .../include/asm/arch-ivybridge/fsp/fsp_configs.h   | 40 +++
>>  arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h  | 12 ++
>>  6 files changed, 131 insertions(+)
>>  create mode 100644 arch/x86/cpu/ivybridge/fsp_configs.c
>>  create mode 100644 arch/x86/cpu/ivybridge/ivybridge.c
>>  create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h
>>  create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 
>
> One question: why do we need an Intel license on this code?
>

It was a copy and paste from other platform (queensbay and baytrail)
files. Do you think we should change it to GPLv2+?

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

Re: [U-Boot] [PATCH 05/10] superio: Add SMSC SIO1007 driver

[Bin Meng]

Hi Simon,

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> The SMSC SIO1007 superio chipset integrates two ns16550 compatible
>> serial ports for legacy applications, 16 GPIO pins and some other
>> functionalities like power management.
>>
>> This adds a simple driver to enable serial port and handle GPIO.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  drivers/misc/Makefile   |   1 +
>>  drivers/misc/smsc_sio1007.c | 126 
>> 
>>  include/smsc_sio1007.h  | 115 
>>  3 files changed, 242 insertions(+)
>>  create mode 100644 drivers/misc/smsc_sio1007.c
>>  create mode 100644 include/smsc_sio1007.h
>>
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index aa137f5..6952f8ce 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -29,6 +29,7 @@ ifdef CONFIG_DM_I2C
>>  obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o
>>  endif
>>  obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
>> +obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o
>>  obj-$(CONFIG_STATUS_LED) += status_led.o
>>  obj-$(CONFIG_SANDBOX) += swap_case.o
>>  obj-$(CONFIG_SANDBOX) += syscon_sandbox.o
>> diff --git a/drivers/misc/smsc_sio1007.c b/drivers/misc/smsc_sio1007.c
>> new file mode 100644
>> index 000..79e9e15
>> --- /dev/null
>> +++ b/drivers/misc/smsc_sio1007.c
>> @@ -0,0 +1,126 @@
>> +/*
>> + * Copyright (C) 2015, Bin Meng 
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static inline u8 sio1007_read(int port, int reg)
>> +{
>> +   outb(reg, port);
>> +
>> +   return inb(port + 1);
>> +}
>> +
>> +static inline void sio1007_write(int port, int reg, int val)
>> +{
>> +   outb(reg, port);
>> +   outb(val, port + 1);
>> +}
>> +
>> +static inline void sio1007_clrsetbits(int port, int reg, u8 clr, u8 set)
>> +{
>> +   sio1007_write(port, reg, (sio1007_read(port, reg) & ~clr) | set);
>> +}
>> +
>> +void sio1007_enable_serial(int port, int num, int iobase, int irq)
>> +{
>> +   if (num < 0 || num > SIO1007_UART_NUM)
>> +   return;
>> +
>> +   /* enter configuration state */
>> +   outb(0x55, port);
>> +
>> +   /* power on serial port and set up its i/o base & irq */
>> +   if (!num) {
>> +   sio1007_clrsetbits(port, DEV_POWER_CTRL, 0, UART1_POWER_ON);
>> +   sio1007_clrsetbits(port, UART1_IOBASE, 0xfe, iobase >> 2);
>> +   sio1007_clrsetbits(port, UART_IRQ, 0xf0, irq << 4);
>> +   } else {
>> +   sio1007_clrsetbits(port, DEV_POWER_CTRL, 0, UART2_POWER_ON);
>> +   sio1007_clrsetbits(port, UART2_IOBASE, 0xfe, iobase >> 2);
>> +   sio1007_clrsetbits(port, UART_IRQ, 0x0f, irq);
>> +   }
>> +
>> +   /* exit configuration state */
>> +   outb(0xaa, port);
>> +}
>> +
>> +void sio1007_enable_runtime(int port, int iobase)
>> +{
>> +   /* enter configuration state */
>> +   outb(0x55, port);
>> +
>> +   /* set i/o base for the runtime register block */
>> +   sio1007_clrsetbits(port, RTR_IOBASE_LOW, 0, iobase >> 4);
>> +   sio1007_clrsetbits(port, RTR_IOBASE_HIGH, 0, iobase >> 12);
>> +   /* turn on address decoding for this block */
>> +   sio1007_clrsetbits(port, DEV_ACTIVATE, 0, RTR_EN);
>> +
>> +   /* exit configuration state */
>> +   outb(0xaa, port);
>> +}
>> +
>> +void sio1007_gpio_config(int port, int gpio, int dir, int pol, int type)
>> +{
>> +   int reg = GPIO0_DIR;
>> +
>> +   if (gpio < 0 || gpio > SIO1007_GPIO_NUM)
>> +   return;
>> +   if (gpio >= GPIO_NUM_PER_GROUP) {
>> +   reg = GPIO1_DIR;
>> +   gpio -= GPIO_NUM_PER_GROUP;
>> +   }
>> +
>> +   /* enter configuration state */
>> +   outb(0x55, port);
>> +
>> +   /* set gpio pin direction, polority and type */
>> +   sio1007_clrsetbits(port, reg, 1 << gpio, dir << gpio);
>> +   sio1007_clrsetbits(port, reg + 1, 1 << gpio, pol << gpio);
>> +   sio1007_clrsetbits(port, reg + 2, 1 << gpio, type << gpio);
>> +
>> +   /* exit configuration state */
>> +   outb(0xaa, port);
>> +}
>> +
>> +int sio1007_gpio_get_value(int port, int gpio)
>> +{
>> +   int reg = GPIO0_DATA;
>> +   int val;
>> +
>> +   if (gpio < 0 || gpio > SIO1007_GPIO_NUM)
>> +   return -EINVAL;
>> +   if (gpio >= GPIO_NUM_PER_GROUP) {
>> +   reg = GPIO1_DATA;
>> +   gpio -= GPIO_NUM_PER_GROUP;
>> +   }
>> +
>> +   val = inb(port + reg);
>> +   if (val & (1 << gpio))
>> +   return 1;
>> +   else
>> +   return 0;
>> +}
>> +
>> +void sio1007_gpio_set_value(int port, int gpio, int val)
>> +{
>> +   int reg = GPIO0_DATA;
>> +   u8 data;
>> +
>> + 

Re: [U-Boot] [PATCH] spi: sf: add support for throughput mesurement of sf read/write

[Stefan Roese]

On 21.12.2015 06:37, Mugunthan V N wrote:

On Friday 18 December 2015 11:37 AM, Stefan Roese wrote:

On 17.12.2015 17:44, Jagan Teki wrote:

On 17 December 2015 at 13:26, Mugunthan V N  wrote:

On Thursday 17 December 2015 12:43 PM, Jagan Teki wrote:

On 17 December 2015 at 12:33, Mugunthan V N 
wrote:

Jagan

On Tuesday 27 October 2015 07:24 PM, Mugunthan V N wrote:

This patch adds time measurement and throughput calculation for
sf read/write commands.

The output of sf read changes from

---8<---
SF: 4096 bytes @ 0x0 Read: OK
--->8---

to

---8<---
SF: 4096 bytes @ 0x0 Read: OK in 6 ms (666 KiB/s)
--->8---

Signed-off-by: Mugunthan V N 


Was it similar to 'sf update' ? please check it once.



sf update out similar but also uses progressive output, in read/write
case it can't be done. The final throughput measurement is similar on
both update and read/write.


True, that's what if we need a progressed throughput just use 'sf
update' else normal 'sf read/write' It's look not good to me to add
extra code on top of generic commands. What ever we wanted to extend
features let's added it on 'sf update' than sf read/write, Sorry.


If I need to measure the time of commands, I use the "time"
command ("time sf write ...") by enabling it via CONFIG_CMD_TIME.
This provides all the needed information to detect performance
changes.



But similar kind of implementations is present for fatload and tftp. So
I thought having similar performance log for sf read/write will be good
as well.


Yes, I understand. I also find this output helpful. But I'm not sure,
if we should add this timing code to all these functions. Instead
of just using this common time command, if needed. To keep the
code size at a minimum.

Of course its no big code addition, so I don't really have any bigger
reservations against it.

Thanks,
Stefan

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

Re: [U-Boot] [PATCH 01/10] fdtdec: Add compatible string for Intel IvyBridge FSP

[Bin Meng]

Hi Simon,

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> Use "intel,ivybridge-fsp" for Intel IvyBridge FSP compatible string.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  include/fdtdec.h | 1 +
>>  lib/fdtdec.c | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 7fe657d..c515a3c 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -169,6 +169,7 @@ enum fdt_compat_id {
>> COMPAT_ALTERA_SOCFPGA_DWMMC,/* SoCFPGA DWMMC controller */
>> COMPAT_INTEL_BAYTRAIL_FSP,  /* Intel Bay Trail FSP */
>> COMPAT_INTEL_BAYTRAIL_FSP_MDP,  /* Intel FSP memory-down params */
>> +   COMPAT_INTEL_IVYBRIDGE_FSP, /* Intel Ivy Bridge FSP */
>>
>> COMPAT_COUNT,
>>  };
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index 82d0090..002594d 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -73,6 +73,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>> COMPAT(ALTERA_SOCFPGA_DWMMC, "altr,socfpga-dw-mshc"),
>> COMPAT(COMPAT_INTEL_BAYTRAIL_FSP, "intel,baytrail-fsp"),
>> COMPAT(COMPAT_INTEL_BAYTRAIL_FSP_MDP, "intel,baytrail-fsp-mdp"),
>> +   COMPAT(COMPAT_INTEL_IVYBRIDGE_FSP, "intel,ivybridge-fsp"),
>>  };
>>
>>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
>> --
>> 1.8.2.1
>>
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 
>
> We should create an FSP uclass I think.

Maybe, I will add this in my todo list for next release.

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

[U-Boot] [PATCH] At start of autoboot check, flush any pending RX bytes

[Craig McQueen]

This is to avoid the boot sequence halting due to initial "junk"
received on serial input.

Signed-off-by: Craig McQueen 
---
I have found that on the BeagleBone Black, U-Boot occasionally halts at 
the U-Boot prompt at boot-up, whether power-up, warm external 
reset or software reset. I have seen other people report the same issue.

This seems to be due to U-Boot receiving "junk" data on the serial 
console. The BeagleBone Black has a pull-down resistor which was 
apparently added to try to mitigate this issue, but it doesn't entirely 
fix it.

 common/autoboot.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/common/autoboot.c b/common/autoboot.c
index c11fb31..3ab51d9 100644
--- a/common/autoboot.c
+++ b/common/autoboot.c
@@ -230,19 +230,29 @@ static int abortboot_normal(int bootdelay)
printf("Hit any key to stop autoboot: %2d ", bootdelay);
 #endif
 
-#if defined CONFIG_ZERO_BOOTDELAY_CHECK
/*
-* Check if key already pressed
-* Don't check if bootdelay < 0
+* Flush any pending input key presses.
+* On some systems, there might be some junk input.
+* No need if bootdelay < 0.
 */
if (bootdelay >= 0) {
-   if (tstc()) {   /* we got a key press   */
+   ts = get_timer(0);
+   while (tstc()) {/* we got a key press   */
(void) getc();  /* consume input*/
+#if defined CONFIG_ZERO_BOOTDELAY_CHECK
puts("\b\b\b 0");
abort = 1;  /* don't auto boot  */
+   break;
+#else
+   /*
+* Sanity check just to avoid infinite loop. It should
+* never happen if hardware is working as expected.
+*/
+   if (get_timer(ts) >= 1000)
+   break;
+#endif
}
}
-#endif
 
while ((bootdelay > 0) && (!abort)) {
--bootdelay;
-- 
2.1.4

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

[U-Boot] [PATCH] imx_watchdog: always set minimal timeout in reset_cpu

[Andrey Skvortsov]

The problem is that timeout bits in WCR register were leaved unchanged.
So previously set timeout value was applied and therefore 'reset'
command takes any value up to two minutes, depending on previous
watchdog settings, instead of minimal 0.5 seconds.

Signed-off-by: Andrey Skvortsov 
---
 drivers/watchdog/imx_watchdog.c | 2 +-
 include/fsl_wdog.h  | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/imx_watchdog.c b/drivers/watchdog/imx_watchdog.c
index 0d77595..f9f8175 100644
--- a/drivers/watchdog/imx_watchdog.c
+++ b/drivers/watchdog/imx_watchdog.c
@@ -43,7 +43,7 @@ void reset_cpu(ulong addr)
 {
struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
 
-   clrsetbits_le16(>wcr, 0, WCR_WDE);
+   clrsetbits_le16(>wcr, WCR_WT_MSK, WCR_WDE);
 
writew(0x, >wsr);
writew(0x, >wsr); /* load minimum 1/2 second timeout */
diff --git a/include/fsl_wdog.h b/include/fsl_wdog.h
index d15a70c..f698d4d 100644
--- a/include/fsl_wdog.h
+++ b/include/fsl_wdog.h
@@ -16,3 +16,4 @@ struct watchdog_regs {
 #define WCR_WDT0x08
 #define WCR_SRS0x10
 #define SET_WCR_WT(x)  (x << 8)
+#define WCR_WT_MSK SET_WCR_WT(0xFF)
-- 
2.6.4

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

Re: [U-Boot] [PATCH v2 6/9] x86: fsp: Introduce CONFIG_FSP_USE_UPD Kconfig option

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:03, Bin Meng  wrote:
>> Not every FSP supports UPD, thus we introduce a Kconfig option
>> CONFIG_FSP_USE_UPD and use it to wrap these common UPD handling
>> codes in fsp_support.c.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - New patch to introduce CONFIG_FSP_USE_UPD Kconfig option
>>
>>  arch/x86/Kconfig   |  9 +
>>  arch/x86/lib/fsp/fsp_support.c | 23 ++-
>>  2 files changed, 23 insertions(+), 9 deletions(-)
>
> Acked-by: Simon Glass 
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/9] x86: fsp: Add boot_mode as a member of struct shared_data

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:02, Bin Meng  wrote:
>> Save boot_mode in struct shared_data for future refactoring.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/include/asm/fsp/fsp_support.h | 1 +
>>  arch/x86/lib/fsp/fsp_support.c | 1 +
>>  2 files changed, 2 insertions(+)
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/9] x86: fsp: Simplify fsp_continue()

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:02, Bin Meng  wrote:
>> There is no need to pass shared_data to fsp_continue() so we can
>> remove unnecessary codes that simplifies the function a lot.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/include/asm/fsp/fsp_support.h |  4 +---
>>  arch/x86/lib/fsp/fsp_support.c | 29 ++---
>>  2 files changed, 7 insertions(+), 26 deletions(-)
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/9] x86: fsp: Avoid cast stack_top in struct shared_data

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:02, Bin Meng  wrote:
>> Declare stack_top as u32 in struct shared_data and struct common_buf
>> so that we can avoid casting in fsp_init().
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/include/asm/fsp/fsp_api.h | 2 +-
>>  arch/x86/include/asm/fsp/fsp_support.h | 2 +-
>>  arch/x86/lib/fsp/fsp_support.c | 4 ++--
>>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/9] x86: fsp: Rename shared_data to fsp_config_data

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:02, Bin Meng  wrote:
>> FSP has several config data like UPD, HDA verb table which can be
>> overridden or provided by bootloader. Currently in U-Boot only UPD
>> is handled via struct shared_data. To accommodate any platform, we
>> rename shared_data to fsp_config_data and move the definition from
>> common place fsp_support.h to platform-specific place fsp_configs.h.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - Include a common struct fsp_cfg_common in the struct fsp_config_data.
>>
>>  arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h  | 15 +++
>>  arch/x86/include/asm/arch-queensbay/fsp/fsp_configs.h | 15 +++
>>  arch/x86/include/asm/fsp/fsp_api.h| 10 ++
>>  arch/x86/include/asm/fsp/fsp_support.h|  8 +---
>>  arch/x86/lib/fsp/fsp_support.c| 10 +-
>>  5 files changed, 46 insertions(+), 12 deletions(-)
>>  create mode 100644 arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h
>>  create mode 100644 arch/x86/include/asm/arch-queensbay/fsp/fsp_configs.h
>
> Acked-by: Simon Glass 
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 9/9] x86: fsp: Set up init runtime buffer in update_fsp_configs()

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:03, Bin Meng  wrote:
>> fsp_init() runtime buffer parameter might be different across
>> different platforms. Move this to update_fsp_configs().
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - split this patch from v1 patch#7
>>
>>  arch/x86/cpu/baytrail/fsp_configs.c| 8 +++-
>>  arch/x86/cpu/queensbay/fsp_configs.c   | 8 +++-
>>  arch/x86/include/asm/fsp/fsp_support.h | 4 +++-
>>  arch/x86/lib/fsp/fsp_support.c | 7 +--
>>  4 files changed, 18 insertions(+), 9 deletions(-)
>
> Acked-by: Simon Glass 
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/9] x86: fsp: Rename update_fsp_upd() and change its signature

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:03, Bin Meng  wrote:
>> To support platform-specific configurations (might not always be
>> UPD on some platform), use a better name update_fsp_configs() and
>> accepct struct fsp_config_data as its parameter so that platform
>> codes can handle whatever configuration data for that FSP.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/baytrail/fsp_configs.c|  5 +++--
>>  arch/x86/cpu/queensbay/fsp_configs.c   |  2 +-
>>  arch/x86/include/asm/fsp/fsp_support.h |  6 +++---
>>  arch/x86/lib/fsp/fsp_support.c | 12 ++--
>>  4 files changed, 13 insertions(+), 12 deletions(-)
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2 v3] usb: Move determination of TT hub address/port into seperate function

[Hans de Goede]

Hi,

On 19-12-15 21:26, Stefan Brüns wrote:

Start split and complete split tokens need the hub address and the
downstream port of the first HS hub (device view).

The core of the function was duplicated in both host/ehci_hcd and
musb-new/usb-compat.h.

Signed-off-by: Stefan Brüns 
---
v2: - renamed function to usb_find_usb2_hub_address_port()
 - put musb port numbering change into seperate patch
v3: - do one assignement per line


Thanks, I've tried to test this, but it seems that musb-new support in
current master is broken in host mode when using hubs even when not
adding your patch, so I need to debug that first...

Note that your patch for musb-new does not even compile, you need this
compile fix:

@@ -2094,7 +2094,8 @@ int musb_urb_enqueue(
if (tt_needed(musb, urb->dev)) {
uint8_t portnr = 0;
uint8_t hubaddr = 0;
-   usb_find_usb2_hub_address_port(udev, ,
+   usb_find_usb2_hub_address_port(urb->dev,
+  ,
   );
qh->h_addr_reg = hubaddr;
qh->h_port_reg = portnr - 1;

But with that still things do not work (as said current master seems broken 
atm).

Regards,

Hans




  common/usb.c  | 56 +++
  drivers/usb/host/ehci-hcd.c   | 50 --
  drivers/usb/musb-new/musb_host.c  |  9 ---
  drivers/usb/musb-new/usb-compat.h | 53 
  include/usb.h | 12 +
  5 files changed, 79 insertions(+), 101 deletions(-)

diff --git a/common/usb.c b/common/usb.c
index cc79695..41efe27 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1213,4 +1213,60 @@ bool usb_device_has_child_on_port(struct usb_device 
*parent, int port)
  #endif
  }

+#ifdef CONFIG_DM_USB
+void usb_find_usb2_hub_address_port(struct usb_device *udev,
+  uint8_t *hub_address, uint8_t *hub_port)
+{
+   struct udevice *parent;
+   struct usb_device *uparent, *ttdev;
+
+   /*
+* When called from usb-uclass.c: usb_scan_device() udev->dev points
+* to the parent udevice, not the actual udevice belonging to the
+* udev as the device is not instantiated yet. So when searching
+* for the first usb-2 parent start with udev->dev not
+* udev->dev->parent .
+*/
+   ttdev = udev;
+   parent = udev->dev;
+   uparent = dev_get_parent_priv(parent);
+
+   while (uparent->speed != USB_SPEED_HIGH) {
+   struct udevice *dev = parent;
+
+   if (device_get_uclass_id(dev->parent) != UCLASS_USB_HUB) {
+   printf("Error: Cannot find high speed parent of usb-1 
device\n");
+   *hub_address = 0;
+   *hub_port = 0;
+   return;
+   }
+
+   ttdev = dev_get_parent_priv(dev);
+   parent = dev->parent;
+   uparent = dev_get_parent_priv(parent);
+   }
+   *hub_address = uparent->devnum;
+   *hub_port = ttdev->portnr;
+}
+#else
+void usb_find_usb2_hub_address_port(struct usb_device *udev,
+  uint8_t *hub_address, uint8_t *hub_port)
+{
+   /* Find out the nearest parent which is high speed */
+   while (udev->parent->parent != NULL)
+   if (udev->parent->speed != USB_SPEED_HIGH) {
+   udev = udev->parent;
+   } else {
+   *hub_address = udev->parent->devnum;
+   *hub_port = udev->portnr;
+   return;
+   }
+
+   printf("Error: Cannot find high speed parent of usb-1 device\n");
+   *hub_address = 0;
+   *hub_port = 0;
+}
+#endif
+
+
  /* EOF */
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c85dbce..af025de 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -279,56 +279,16 @@ static inline u8 ehci_encode_speed(enum usb_device_speed 
speed)
  static void ehci_update_endpt2_dev_n_port(struct usb_device *udev,
  struct QH *qh)
  {
-   struct usb_device *ttdev;
-   int parent_devnum;
+   uint8_t portnr = 0;
+   uint8_t hubaddr = 0;

if (udev->speed != USB_SPEED_LOW && udev->speed != USB_SPEED_FULL)
return;

-   /*
-* For full / low speed devices we need to get the devnum and portnr of
-* the tt, so of the first upstream usb-2 hub, there may be usb-1 hubs
-* in the tree before that one!
-*/
-#ifdef CONFIG_DM_USB
-   /*
-* When called from usb-uclass.c: usb_scan_device() udev->dev points

[U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix D709 tablet

[Hans de Goede]

The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone jack.

Empire Electronix is written on the back of the tablet, the D709 model
info can be found in the about tablet menu in android.

The PCB has no markings to speak of.

This dts file is identical to the one submitted to the upstream kernel.

Signed-off-by: Hans de Goede 
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sun5i-a13-empire-electronix-d709.dts | 241 ++
 board/sunxi/MAINTAINERS   |   1 +
 configs/Empire_electronix_d709_defconfig  |  24 +++
 4 files changed, 267 insertions(+)
 create mode 100644 arch/arm/dts/sun5i-a13-empire-electronix-d709.dts
 create mode 100644 configs/Empire_electronix_d709_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 03f984a..0bcd316 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -125,6 +125,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a10s-wobo-i5.dtb \
sun5i-a13-ampe-a76.dtb \
+   sun5i-a13-empire-electronix-d709.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-86vs.dtb \
sun5i-a13-inet-98v-rev2.dtb \
diff --git a/arch/arm/dts/sun5i-a13-empire-electronix-d709.dts 
b/arch/arm/dts/sun5i-a13-empire-electronix-d709.dts
new file mode 100644
index 000..7fbb0b0
--- /dev/null
+++ b/arch/arm/dts/sun5i-a13-empire-electronix-d709.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright 2015 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Empire Electronix D709 tablet";
+   compatible = "empire-electronix,d709", "allwinner,sun5i-a13";
+
+   aliases {
+   serial0 = 
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   /* TODO: backlight uses axp gpio1 as enable pin */
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   pcf8563: rtc@51 {
+   compatible = "nxp,pcf8563";
+   reg = <0x51>;
+   };
+};
+
+ {
+   vref-supply = <_ldo2>;
+   status = "okay";
+
+   button@200 {
+   label = "Volume Up";
+   linux,code 

[U-Boot] header files in include/ versus arch//include/asm/?

[Robert P. J. Day]

  working on MPC8360-based project and noticed that what appears to be
a powerpc-specific header file (include/fsl_immap.h) is in the
top-level include/ directory, as opposed to where i would have
expected it (arch/powerpc/include/asm/).

  it's not the only one ... there appear to be others. what is the
rationale for installing a header file if it *appears* to be
architecture-specific? it seems like there's a fair bit of freescale
powerpc content under include/, but maybe i'm just misreading this.

rday

-- 


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

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


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

Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly

[Matwey V. Kornilov]

2015-12-20 1:29 GMT+03:00 Robert Nelson :
>>> ah, it's tripping on the "." = "0a" character..
>>>
>>> Do you happen to remember where you purchased it and what it was
>>> called.. (for git commit)
>>>
>>> This patch should work:
>>>
>>> https://gist.github.com/RobertCNelson/21f44591c78daed7c637
>>>
>>
>> The patch works good.
>> But could you please explain me? I thought the problem was in 'test' 
>> operator.
>> Unlikely
>> test '\0x74\0x0a\0x75\0x65' = BBG1
>> should be true.
>
> I saw this when i first booted the Green with the production eeprom,
> "test" doesn't seem to like non printable characters..

Seems, issue is in command parser, not in test itself.

>
> Sorry i didn't look into "test" much further..
>
> Instead i just worked around it with the Green..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/



-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2...@jabber.ru
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot 2016.01-rc2 detects BeagleBone Black incorrectly

[Tom Rini]

On Sun, Dec 20, 2015 at 12:57:33PM +0300, Matwey V. Kornilov wrote:
> 2015-12-20 1:29 GMT+03:00 Robert Nelson :
> >>> ah, it's tripping on the "." = "0a" character..
> >>>
> >>> Do you happen to remember where you purchased it and what it was
> >>> called.. (for git commit)
> >>>
> >>> This patch should work:
> >>>
> >>> https://gist.github.com/RobertCNelson/21f44591c78daed7c637
> >>>
> >>
> >> The patch works good.
> >> But could you please explain me? I thought the problem was in 'test' 
> >> operator.
> >> Unlikely
> >> test '\0x74\0x0a\0x75\0x65' = BBG1
> >> should be true.
> >
> > I saw this when i first booted the Green with the production eeprom,
> > "test" doesn't seem to like non printable characters..
> 
> Seems, issue is in command parser, not in test itself.

Yeah.  You may be able to instead use 'cmp.w' and mw to try and keep all
of this inside just the script side of things and outside of C.  That
also however may end up being even uglier.

-- 
Tom


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

Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the parameter is NULL

[Qianyu Gong]

> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Friday, December 18, 2015 6:24 PM
> To: Gong Qianyu-B52263
> Cc: u-boot@lists.denx.de; Stefano Babic
> Subject: Re: [U-Boot] [Patch V3] i2c: mxc: add a condition in case the
> parameter is NULL
> 
> Hello Gong Qianyu,
> 
> added Stefano Babic to cc as he is the imx maintainer.
> 
> Am 18.12.2015 um 10:38 schrieb Gong Qianyu:
> > This could avoid executing the code that only applies to i.MX platforms.
> >
> > The bus_i2c_init() is called before relocation and will assgin value
> > to a static variable. If U-Boot is then still running in a flash
> > device, it's theoretically not allowed to write data to flash without
> > an erasing operation. For i.MX platforms, the U-Boot is always running
> > in DDR.
> >
> > Actually it causes asynchronous error when the ARM64 system error
> > report is enabled and the flash write protect is set.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V3:
> >   - Sorry..Remove an unrelated line in other file.
> >
> >   drivers/i2c/mxc_i2c.c | 12 ++--
> >   1 file changed, 10 insertions(+), 2 deletions(-)
> 
> Ok, from my side, but it would be better to switch your board(s) to
> support DM and get rid of this old stuff from this driver.
> 
> Reviewed-by: Heiko Schocher 
> 
> bye,
> Heiko

Thanks. But I have no control over this driver. Maybe they are considering to 
convert it later.

Regards,
Qianyu

> >
> > diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index
> > fa4c82f..b2d15c9 100644
> > --- a/drivers/i2c/mxc_i2c.c
> > +++ b/drivers/i2c/mxc_i2c.c
> > @@ -581,8 +581,16 @@ void bus_i2c_init(int index, int speed, int unused,
> > return;
> > }
> >
> > -   mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > -   mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> > +   /*
> > +* Warning: Be careful to allow the assignment to a static
> > +* variable here. This function could be called while U-Boot is
> > +* still running in flash memory. So such assignment is equal
> > +* to write data to flash without erasing.
> > +*/
> > +   if (idle_bus_fn)
> > +   mxc_i2c_buses[index].idle_bus_fn = idle_bus_fn;
> > +   if (idle_bus_data)
> > +   mxc_i2c_buses[index].idle_bus_data = idle_bus_data;
> >
> > ret = enable_i2c_clk(1, index);
> > if (ret < 0) {
> >
> 
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Saturday, December 19, 2015 10:51 AM
> To: Gong Qianyu
> Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> yao.y...@freescale.com; Jagan Teki
> Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> Hi Gong,
> 
> On 15 December 2015 at 03:32, Gong Qianyu 
> wrote:
> >
> > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> >
> > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V2:
> >  - New Patch.
> >
> >  common/env_sf.c | 49
> > +
> >  1 file changed, 49 insertions(+)
> 
> The 'saveenv' command seems to work OK for me with driver model. Can you
> please explain what problem this patch solves?
> 
> Regards,
> Simon

Hi Simon,

The saveenv() always keeps the latest 'sf probe' value of env_flash. So if I 
run 'sf probe' 
a few more times till it returns a different value, saveenv() will then get 
into sync abort.

Actually the problem I met is:
=> saveenv
Saving Environment to SPI Flash...
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16MiB
Erasing SPI flash...Writing to SPI flash...done
=> sf probe
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16MiB
=> saveenv
Saving Environment to SPI Flash...
"Synchronous Abort" handler, esr 0x0200
ELR: fffa8520
LR:  fff6fd28
x0 : ffe44850 x1 : 00102000
x2 : e000 x3 : ffe6a670
x4 : fffa8520 x5 : fffa89c0
x6 : fffa8340 x7 : 0053
x8 :  x9 : 000c
x10: ffe6a660 x11: fff9
x12: 000f x13: 4000
x14: 0020 x15: fff490d0
x16: fff4984c x17: 0064
x18: ffe43da0 x19: fffb7000
x20: ffe6a670 x21: fffb7000
x22: fffb7000 x23: 0001
x24: fffb6db0 x25: 
x26:  x27: 
x28:  x29: ffe3f4d0

Resetting CPU ...

resetting ...



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

[U-Boot] Uboot Image

[P.XP]

Hello,
   I'm a graduate student,how can I get your  post Pre-built (and tested) 
images are available from ftp://ftp.denx.de/pub/u-boot/images/ ?
  Can you tell me the login count and password?
  Thans a lot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] x86: ivybridge: Add microcode blobs for all the steppings

[Bin Meng]

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> This adds microcode blobs created from Intel FSP package for the
>> Chief River platform. They are for all the Ivy Bridge steppings:
>> 306a2 (B0), 306a4 (C0), 306a5 (K0/M0), 306a8 (E0/L0), except the
>> 306a9 which is already in the U-Boot tree.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/dts/microcode/m12306a2_0008.dtsi | 554 +
>>  arch/x86/dts/microcode/m12306a4_0007.dtsi | 618 +++
>>  arch/x86/dts/microcode/m12306a5_0007.dtsi | 618 +++
>>  arch/x86/dts/microcode/m12306a8_0010.dtsi | 682 
>> ++
>>  4 files changed, 2472 insertions(+)
>>  create mode 100644 arch/x86/dts/microcode/m12306a2_0008.dtsi
>>  create mode 100644 arch/x86/dts/microcode/m12306a4_0007.dtsi
>>  create mode 100644 arch/x86/dts/microcode/m12306a5_0007.dtsi
>>  create mode 100644 arch/x86/dts/microcode/m12306a8_0010.dtsi
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] fdtdec: Add compatible string for Intel IvyBridge FSP

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> Use "intel,ivybridge-fsp" for Intel IvyBridge FSP compatible string.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  include/fdtdec.h | 1 +
>>  lib/fdtdec.c | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> index 7fe657d..c515a3c 100644
>> --- a/include/fdtdec.h
>> +++ b/include/fdtdec.h
>> @@ -169,6 +169,7 @@ enum fdt_compat_id {
>> COMPAT_ALTERA_SOCFPGA_DWMMC,/* SoCFPGA DWMMC controller */
>> COMPAT_INTEL_BAYTRAIL_FSP,  /* Intel Bay Trail FSP */
>> COMPAT_INTEL_BAYTRAIL_FSP_MDP,  /* Intel FSP memory-down params */
>> +   COMPAT_INTEL_IVYBRIDGE_FSP, /* Intel Ivy Bridge FSP */
>>
>> COMPAT_COUNT,
>>  };
>> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>> index 82d0090..002594d 100644
>> --- a/lib/fdtdec.c
>> +++ b/lib/fdtdec.c
>> @@ -73,6 +73,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
>> COMPAT(ALTERA_SOCFPGA_DWMMC, "altr,socfpga-dw-mshc"),
>> COMPAT(COMPAT_INTEL_BAYTRAIL_FSP, "intel,baytrail-fsp"),
>> COMPAT(COMPAT_INTEL_BAYTRAIL_FSP_MDP, "intel,baytrail-fsp-mdp"),
>> +   COMPAT(COMPAT_INTEL_IVYBRIDGE_FSP, "intel,ivybridge-fsp"),
>>  };
>>
>>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
>> --
>> 1.8.2.1
>>
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 
>

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/10] x86: ivybridge: Do not require HAVE_INTEL_ME

[Bin Meng]

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> Do not set HAVE_INTEL_ME by default as for some cases Intel ME
>> firmware even does not reside on the same SPI flash as U-Boot.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/ivybridge/Kconfig | 1 -
>>  board/google/chromebook_link/Kconfig   | 1 +
>>  board/google/chromebox_panther/Kconfig | 1 +
>>  3 files changed, 2 insertions(+), 1 deletion(-)
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/10] tools: microcode-tool: Support parsing header file with a license block

[Bin Meng]

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> The microcode header files in the Intel Chief River FSP package have
>> a license comment block. Update the microcode-tool to support parsing
>> it and extract the license text to the .dtsi file.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  tools/microcode-tool.py | 14 ++
>>  1 file changed, 14 insertions(+)
>
> Acked-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/10] x86: fsp: Always use hex numbers in the hob command output

[Bin Meng]

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> In the 'fsp hob' command output, decimal numbers and hexadecimal
>> numbers are used mixedly. Now change to always use hex numbers
>> to keep consistency.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/lib/fsp/cmd_fsp.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 09/10] x86: ivybridge: Add macros for LPC decode ranges

[Bin Meng]

On Sat, Dec 19, 2015 at 10:52 AM, Simon Glass  wrote:
> On 11 December 2015 at 03:55, Bin Meng  wrote:
>> Add several macros for LPC decode registers on PCH.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/include/asm/arch-ivybridge/pch.h | 10 ++
>>  1 file changed, 10 insertions(+)
>
> Acked-by: Simon Glass 
> Tested on link (ivybridge non-FSP)
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model

[Qianyu Gong]

> -Original Message-
> From: Qianyu Gong
> Sent: Monday, December 21, 2015 1:25 PM
> To: 'Simon Glass'; Gong Qianyu
> Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> yao.y...@freescale.com; Jagan Teki
> Subject: RE: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver model
> 
> 
> 
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: Saturday, December 19, 2015 10:51 AM
> > To: Gong Qianyu
> > Cc: U-Boot Mailing List; Mingkai Hu; r58...@freescale.com;
> > yao.y...@freescale.com; Jagan Teki
> > Subject: Re: [Patch V2 4/4] dm: env_sf: fix saveenv() to use driver
> > model
> >
> > Hi Gong,
> >
> > On 15 December 2015 at 03:32, Gong Qianyu 
> > wrote:
> > >
> > > It might be missed when converting spi_flash_probe() in cmd_sf.c.
> > >
> > > This commit refers to fbb099183e3a53f77a975964cdf2e73d11e565af.
> > >
> > > Signed-off-by: Gong Qianyu 
> > > ---
> > > V2:
> > >  - New Patch.
> > >
> > >  common/env_sf.c | 49
> > > +
> > >  1 file changed, 49 insertions(+)
> >
> > The 'saveenv' command seems to work OK for me with driver model. Can
> > you please explain what problem this patch solves?
> >
> > Regards,
> > Simon
> 
> Hi Simon,
> 
> The saveenv() always keeps the latest 'sf probe' value of env_flash. So
> if I run 'sf probe'
> a few more times till it returns a different value, saveenv() will then
> get into sync abort.
> 
> Actually the problem I met is:
> => saveenv
> Saving Environment to SPI Flash...
> SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB,
> total 16MiB Erasing SPI flash...Writing to SPI flash...done => sf probe
> SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB,
> total 16MiB => saveenv Saving Environment to SPI Flash...
> "Synchronous Abort" handler, esr 0x0200
> ELR: fffa8520
> LR:  fff6fd28
> x0 : ffe44850 x1 : 00102000
> x2 : e000 x3 : ffe6a670
> x4 : fffa8520 x5 : fffa89c0
> x6 : fffa8340 x7 : 0053
> x8 :  x9 : 000c
> x10: ffe6a660 x11: fff9
> x12: 000f x13: 4000
> x14: 0020 x15: fff490d0
> x16: fff4984c x17: 0064
> x18: ffe43da0 x19: fffb7000
> x20: ffe6a670 x21: fffb7000
> x22: fffb7000 x23: 0001
> x24: fffb6db0 x25: 
> x26:  x27: 
> x28:  x29: ffe3f4d0
> 
> Resetting CPU ...
> 
> resetting ...
> 
> 

This patch makes 'saveenv' probes the flash every time like 'sf probe'. Maybe 
there is a better way
to solve this. I'm also confused why the current 'sf probe' may return 
different 
values for the same SPI flash(the same cs and bus)..Isn't it freed cleanly?

Regards,
Qianyu

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

Re: [U-Boot] [PATCH v2 8/9] x86: fsp: Move struct fspinit_rtbuf definition to chipset header

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:03, Bin Meng  wrote:
>> All FSP spec v1.0 complaint FSP binary uses struct fspinit_rtbuf
>> as defined by the 1.0 spec, however there are FSPs that does not
>> follow 1.0 spec (possible due to that FSP predates the 1.0 spec),
>> and future FSP binary that is complaint to v1.1 spec defines an
>> optional paltform-specific runtime data in the struct fspinit_rtbuf.
>> Hence move the definition to chipset header.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/include/asm/arch-baytrail/fsp/fsp_configs.h  |  4 
>>  arch/x86/include/asm/arch-queensbay/fsp/fsp_configs.h |  4 
>>  arch/x86/include/asm/fsp/fsp_platform.h   | 15 ---
>>  arch/x86/include/asm/fsp/fsp_support.h|  1 -
>>  4 files changed, 8 insertions(+), 16 deletions(-)
>>  delete mode 100644 arch/x86/include/asm/fsp/fsp_platform.h
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] x86: queensbay: Remove invalid comments in update_fsp_configs()

[Bin Meng]

On Sat, Dec 19, 2015 at 10:51 AM, Simon Glass  wrote:
> On 10 December 2015 at 23:03, Bin Meng  wrote:
>> Those comments in update_fsp_configs() are not correct. Remove them.
>>
>> Signed-off-by: Bin Meng 
>> Acked-by: Simon Glass 
>>
>> ---
>>
>> Changes in v2: None
>>
>>  arch/x86/cpu/queensbay/fsp_configs.c | 6 --
>>  1 file changed, 6 deletions(-)
>
> Tested on Minnowmax:
> Tested-by: Simon Glass 

applied to u-boot-x86/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] Add a new poweroff command and implement it for sunxi

[Hans de Goede]

Hi All,

I've had this idea that it would be good to have a poweroff command in
u-boot in my head for a while now. The reason being that during u-boot
development one often stays in just u-boot (e.g. when testing usb kbd
support), when I'm then done testing having a poweroff command would
be useful, esp. on devices with builtin batteries like tablets where
one cannot just pull the powerplug.

So when Michael (in the Cc, author of 2 of the patches) asked me
if there was a simple u-boot task he could help with I suggested
adding a poweroff command, the result of which is this patch-set.

Tom, can you review the non sunxi specific cmd_boot patch (patch 1/4)
please ?

Regards,

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

[U-Boot] [PATCH 2/4] sunxi: Implement poweroff support for axp152 pmic

[Hans de Goede]

Adds poweroff support for axp152 pmic.

Signed-off-by: Hans de Goede 
---
 drivers/power/Kconfig  |  1 +
 drivers/power/axp152.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index e86dd72..de32828 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -20,6 +20,7 @@ config SUNXI_NO_PMIC
 config AXP152_POWER
boolean "axp152 pmic support"
depends on MACH_SUN5I
+   select CMD_POWEROFF
---help---
Select this to enable support for the axp152 pmic found on most
A10s boards.
diff --git a/drivers/power/axp152.c b/drivers/power/axp152.c
index 2972586..cd07275 100644
--- a/drivers/power/axp152.c
+++ b/drivers/power/axp152.c
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 
@@ -78,3 +79,14 @@ int axp_init(void)
 
return 0;
 }
+
+int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   pmic_bus_write(AXP152_SHUTDOWN, AXP152_POWEROFF);
+
+   /* infinite loop during shutdown */
+   while (1) {}
+
+   /* not reached */
+   return 0;
+}
-- 
2.5.0

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

[U-Boot] [PATCH 1/4] cmd_boot: Add a poweroff command

[Hans de Goede]

From: Michael van Slingerland 

Add a 'poweroff' command to boot commands, this only gets enabled if the
board Kconfig does a "select CMD_POWEROFF".

Signed-off-by: Michael van Slingerland 
[hdego...@redhat.com: Make the cmd conditional on a CMD_POWEROFF Kconfig]
Signed-off-by: Hans de Goede 
---
 common/Kconfig| 3 +++
 common/cmd_boot.c | 8 
 include/command.h | 3 +++
 3 files changed, 14 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index ccf5475..9d446bf 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -184,6 +184,9 @@ config CMD_XIMG
help
  Extract a part of a multi-image.
 
+config CMD_POWEROFF
+   bool
+
 endmenu
 
 menu "Environment commands"
diff --git a/common/cmd_boot.c b/common/cmd_boot.c
index 8f2e070..5a8f912 100644
--- a/common/cmd_boot.c
+++ b/common/cmd_boot.c
@@ -61,3 +61,11 @@ U_BOOT_CMD(
"Perform RESET of the CPU",
""
 );
+
+#ifdef CONFIG_CMD_POWEROFF
+U_BOOT_CMD(
+   poweroff, 1, 0, do_poweroff,
+   "Perform POWEROFF",
+   ""
+);
+#endif
diff --git a/include/command.h b/include/command.h
index 2ae9b6c..30bc327 100644
--- a/include/command.h
+++ b/include/command.h
@@ -110,6 +110,9 @@ extern int common_diskboot(cmd_tbl_t *cmdtp, const char 
*intf, int argc,
   char *const argv[]);
 
 extern int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+#ifdef CONFIG_CMD_POWEROFF
+extern int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[]);
+#endif
 
 /*
  * Error codes that commands return to cmd_process(). We use the standard 0
-- 
2.5.0

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

[U-Boot] [PATCH 4/4] sunxi: Implement poweroff support for axp221 pmic

[Hans de Goede]

Adds poweroff support for axp221 pmic.

Signed-off-by: Hans de Goede 
---
 drivers/power/Kconfig  |  1 +
 drivers/power/axp221.c | 12 
 include/axp221.h   |  2 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 52c9e61..dfd60aa 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -36,6 +36,7 @@ config AXP209_POWER
 config AXP221_POWER
boolean "axp221 / axp223 pmic support"
depends on MACH_SUN6I || MACH_SUN8I_A23 || MACH_SUN8I_A33
+   select CMD_POWEROFF
---help---
Select this to enable support for the axp221/axp223 pmic found on most
A23 and A31 boards.
diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
index 65802e4..8acadf0 100644
--- a/drivers/power/axp221.c
+++ b/drivers/power/axp221.c
@@ -11,6 +11,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -312,3 +313,14 @@ int axp_get_sid(unsigned int *sid)
 
return 0;
 }
+
+int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   pmic_bus_write(AXP221_SHUTDOWN, AXP221_SHUTDOWN_POWEROFF);
+
+   /* infinite loop during shutdown */
+   while (1) {}
+
+   /* not reached */
+   return 0;
+}
diff --git a/include/axp221.h b/include/axp221.h
index 0ee21b6..04cd8c2 100644
--- a/include/axp221.h
+++ b/include/axp221.h
@@ -45,6 +45,8 @@
 #define AXP221_ALDO3_CTRL  0x2a
 #define AXP221_VBUS_IPSOUT 0x30
 #define AXP221_VBUS_IPSOUT_DRIVEBUS(1 << 2)
+#define AXP221_SHUTDOWN0x32
+#define AXP221_SHUTDOWN_POWEROFF   (1 << 7)
 #define AXP221_MISC_CTRL   0x8f
 #define AXP221_MISC_CTRL_N_VBUSEN_FUNC (1 << 4)
 #define AXP221_PAGE0xff
-- 
2.5.0

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

[U-Boot] U-Boot Device Driver Development Guide

[jerroldm]

Dear Sir,
 
I am considering using U-Boot as a software platform to bring up a hardware 
platform that am developing.  In doing so, I may need to develop a couple of 
Device Drivers.  I was wondering if anyone could point me to a document or a 
website that might help guide me to do this in the correction fashion.
 
To be a bit more specific, I have a custom UHS-II SD Card Host Controller which 
I would like to access through FAT and EXFAT commands.  I am using a Zynq FPGA 
as a platform.
 
Thank you,
 
Jerrold
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH V2 0/2] sunxi: support for a second SD card socket

[Hans de Goede]

Hi,

On 16-12-15 20:59, Karsten Merker wrote:

Hello,

this patchset enables the full-size SD card socket on the
A20-Olimex-SOM-EVB baseboard in u-boot and adds support for
including this kind of secondary socket into the boot environment
provided by config_distro_bootcmd.h on sunxi-based systems.

The latter is particularly useful on the A20-Olimex-SOM-EVB as
changing the card in the primary micro-SD socket is kind of
fiddly when the SOM is plugged into the baseboard.

Changes since V1:
I had botched the patch generation for V1 so that the posted
patch was incomplete. This is now the complete patch.


Thanks, both patches look good to me. I've added them to my sunxi-wip
tree (for now) and I will include them in the next sunxi pull-req.

Regards,

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

[U-Boot] [PATCH 3/4] sunxi: Implement poweroff support for axp209 pmic

[Hans de Goede]

From: Michael van Slingerland 

Adds poweroff support for axp209 pmic.

Signed-off-by: Michael van Slingerland 
Signed-off-by: Hans de Goede 
---
 drivers/power/Kconfig  |  1 +
 drivers/power/axp209.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index de32828..52c9e61 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -28,6 +28,7 @@ config AXP152_POWER
 config AXP209_POWER
boolean "axp209 pmic support"
depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+   select CMD_POWEROFF
---help---
Select this to enable support for the axp209 pmic found on most
A10, A13 and A20 boards.
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 71aa000..fc162a1 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -168,3 +169,14 @@ int axp_init(void)
 
return 0;
 }
+
+int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   pmic_bus_write(AXP209_SHUTDOWN, AXP209_POWEROFF);
+
+   /* infinite loop during shutdown */
+   while (1) {}
+
+   /* not reached */
+   return 0;
+}
-- 
2.5.0

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

Re: [U-Boot] [PATCH 1/4] cmd_boot: Add a poweroff command

[Tom Rini]

On Sun, Dec 20, 2015 at 04:41:32PM +0100, Hans de Goede wrote:

> From: Michael van Slingerland 
> 
> Add a 'poweroff' command to boot commands, this only gets enabled if the
> board Kconfig does a "select CMD_POWEROFF".
> 
> Signed-off-by: Michael van Slingerland 
> [hdego...@redhat.com: Make the cmd conditional on a CMD_POWEROFF Kconfig]
> Signed-off-by: Hans de Goede 
> ---
>  common/Kconfig| 3 +++
>  common/cmd_boot.c | 8 
>  include/command.h | 3 +++
>  3 files changed, 14 insertions(+)
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index ccf5475..9d446bf 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -184,6 +184,9 @@ config CMD_XIMG
>   help
> Extract a part of a multi-image.
>  
> +config CMD_POWEROFF
> + bool
> +
>  endmenu
>  
>  menu "Environment commands"
> diff --git a/common/cmd_boot.c b/common/cmd_boot.c
> index 8f2e070..5a8f912 100644
> --- a/common/cmd_boot.c
> +++ b/common/cmd_boot.c
> @@ -61,3 +61,11 @@ U_BOOT_CMD(
>   "Perform RESET of the CPU",
>   ""
>  );
> +
> +#ifdef CONFIG_CMD_POWEROFF
> +U_BOOT_CMD(
> + poweroff, 1, 0, do_poweroff,
> + "Perform POWEROFF",

" of the device"

> + ""
> +);
> +#endif
> diff --git a/include/command.h b/include/command.h
> index 2ae9b6c..30bc327 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -110,6 +110,9 @@ extern int common_diskboot(cmd_tbl_t *cmdtp, const char 
> *intf, int argc,
>  char *const argv[]);
>  
>  extern int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
> +#ifdef CONFIG_CMD_POWEROFF
> +extern int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
> +#endif

No need for ifdef/endif (yes, there's others in the file like that but
that's something to fix sometime).  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/5] lib: Add wait_for_bit

[Mateusz Kulikowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Marek,

On 17.12.2015 00:52, Marek Vasut wrote:
[...]

>> Of course I can make it static inline.
>>
>> I was suggested not to care about possible leftovers that are
>> not garbage-collected by linker so didn't changed that on V2.
>>
>> It's (max) few bytes that may be consumed by section alignment.
> 
> I was just curious about how much difference this would make.

I added one more commit (to do wait_for_bit static inline), and ran 
buildman on 4 boards (2x using and 2x not using wait_bit).

tl;dr: 
For (at least) some boards it increases .rodata by 7 bytes.
Even if they don't use wait_for_bit.
Inline version works better, as it doesn't touch them

My proposal - I'll send v3 with wait_for_bit as static inline...

Buildman output:

$ tools/buildman/buildman -b wait_for_bit_v2 -o buildman  hikey sandbox 
usb_a9263 zynq_picozed -sdSB
boards.cfg is up to date. Nothing to do.
Summary of 7 commits for 4 boards (4 threads, 1 job per thread)
01: eeprom: fix eeprom write procedure
02: lib: Add wait_for_bit
   sandbox: (for 1/1 boards)  all +224.0  text +224.0 
sandbox:  all +224  text +224 
   u-boot: add: 1/0, grow: 0/0 bytes: 137/0 (137)
 function   old new   delta
 wait_for_bit - 137+137
   arm: (for 2/2 boards)  spl/u-boot-spl:all +3.5  spl/u-boot-spl:rodata 
+3.5 
zynq_picozed   :  spl/u-boot-spl:all +7  spl/u-boot-spl:rodata +7 
03: usb: dwc2: Use shared wait_for_bit
   aarch64: (for 1/1 boards)  all +168.0  rodata +16.0  text +152.0 
hikey  :  all +168  rodata +16  text +152 
   u-boot: add: 0/0, grow: 4/0 bytes: 156/0 (156)
 function   old new   delta
 wait_for_bit   104 164 +60
 usb_lowlevel_init  820 864 +44
 dwc_otg_core_reset 120 156 +36
 wait_for_chhltd140 156 +16
04: usb: ohci-lpc32xx: Use shared wait_for_bit
05: usb: ehci-mx6: Use shared wait_for_bit
06: net: zynq_gem: Use shared wait_for_bit
   arm: (for 2/2 boards)  all +53.0  bss +6.0  rodata +7.0  text +40.0 
zynq_picozed   :  all +106  bss +12  rodata +14  text +80 
   u-boot: add: 1/0, grow: 0/-1 bytes: 140/-68 (72)
 function   old new   delta
 wait_for_bit - 140+140
 zynq_gem_send  276 208 -68
07: make wait_bit static inline
   sandbox: (for 1/1 boards)  all -224.0  text -224.0 
sandbox:  all -224  text -224 
   arm: (for 2/2 boards)  spl/u-boot-spl:all -3.5  spl/u-boot-spl:rodata 
-3.5 
zynq_picozed   :  spl/u-boot-spl:all -7  spl/u-boot-spl:rodata -7 


Regards,
Mateusz
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWdtT1AAoJELvtohmVtQzBtPwH/2aY2GbCIevGGdN5x4109xDm
zrrkmu6IQORQeOlTckeP2x83plY2KLGCoMtrA8fN3GbhqAJ9gM9EjtOzo7HYcYyD
fENKksvqSWTGKPI1nAU3liRri6lhCyO0eq+ZwPNvQF8m5GT88r12QL599P1LXgOI
tM93wzTaDWxDVUdFsUgBgzS0arcjG6eE2SWTE9SQY1OIKK/6CY79Y0q4h6UFSXwj
DflZ4rrYTQSMMHs2tKvas/MrZozKHsim2g8glZj87dkVcyeTHPcEEvUa6UPbr4RJ
NTQlarzFR3zsBa4Xl9wbROlL10drb+zgo6eNt8CyZ6z7II1r+oPI2m/OcyHoyDU=
=Lfit
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot Device Driver Development Guide

[Jagan Teki]

On 20 December 2015 at 19:38,   wrote:
>
> Dear Sir,
>
> I am considering using U-Boot as a software platform to bring up a hardware 
> platform that am developing.  In doing so, I may need to develop a couple of 
> Device Drivers.  I was wondering if anyone could point me to a document or a 
> website that might help guide me to do this in the correction fashion.

If you wanted to develop a drivers on u-boot see this [1] driver model
text files for more info.
Each text file has an information on how to write it for respective
IP, there may be some missing IP's text's but you can grep the source
using UCLASS_ then you can easily find the drivers which are writing
using driver model.

If you're new to u-boot, driver model is a new driver design
implementation in u-boot.

> To be a bit more specific, I have a custom UHS-II SD Card Host Controller 
> which I would like to access through FAT and EXFAT commands.  I am using a 
> Zynq FPGA as a platform.

For zynq mmc there is a driver available on source as
drivers/mmc/zynq_sdhci.c see this if you want more info.

[1] 
http://git.denx.de/?p=u-boot.git;a=tree;f=doc/driver-model;h=3312fbcb9336e799c7e8956ac81acfa40f55374b;hb=refs/heads/master

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

[U-Boot] [PATCH v2 2/2] m68k: add DM model serial driver

[Angelo Dureghello]

Boards can now use DM serial driver, or still legacy mcf uart
driver version.

Signed-off-by: Angelo Dureghello 

---

Changes in v2:
- remove while loops in putc and getc, replacing with return -EAGAIN
- remove unneeded ifdef

 drivers/serial/mcfuart.c   | 188 ++---
 include/dm/platform_data/serial_coldfire.h |  23 
 2 files changed, 167 insertions(+), 44 deletions(-)
 create mode 100644 include/dm/platform_data/serial_coldfire.h

diff --git a/drivers/serial/mcfuart.c b/drivers/serial/mcfuart.c
index 407354f..059cb0f 100644
--- a/drivers/serial/mcfuart.c
+++ b/drivers/serial/mcfuart.c
@@ -2,6 +2,9 @@
  * (C) Copyright 2004-2007 Freescale Semiconductor, Inc.
  * TsiChung Liew, tsi-chung.l...@freescale.com.
  *
+ * Modified to add device model (DM) support
+ * (C) Copyright 2015  Angelo Dureghello 
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -11,9 +14,10 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
-
 #include 
 #include 
 
@@ -21,91 +25,110 @@ DECLARE_GLOBAL_DATA_PTR;
 
 extern void uart_port_conf(int port);
 
-static int mcf_serial_init(void)
+static int mcf_serial_init_common(uart_t *uart, int port_idx, int baudrate)
 {
-   volatile uart_t *uart;
u32 counter;
 
-   uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
-
-   uart_port_conf(CONFIG_SYS_UART_PORT);
+   uart_port_conf(port_idx);
 
/* write to SICR: SIM2 = uart mode,dcd does not affect rx */
-   uart->ucr = UART_UCR_RESET_RX;
-   uart->ucr = UART_UCR_RESET_TX;
-   uart->ucr = UART_UCR_RESET_ERROR;
-   uart->ucr = UART_UCR_RESET_MR;
+   writeb(UART_UCR_RESET_RX, >ucr);
+   writeb(UART_UCR_RESET_TX, >ucr);
+   writeb(UART_UCR_RESET_ERROR, >ucr);
+   writeb(UART_UCR_RESET_MR, >ucr);
__asm__("nop");
 
-   uart->uimr = 0;
+   writeb(0, >uimr);
 
/* write to CSR: RX/TX baud rate from timers */
-   uart->ucsr = (UART_UCSR_RCS_SYS_CLK | UART_UCSR_TCS_SYS_CLK);
+   writeb(UART_UCSR_RCS_SYS_CLK | UART_UCSR_TCS_SYS_CLK, >ucsr);
 
-   uart->umr = (UART_UMR_BC_8 | UART_UMR_PM_NONE);
-   uart->umr = UART_UMR_SB_STOP_BITS_1;
+   writeb(UART_UMR_BC_8 | UART_UMR_PM_NONE, >umr);
+   writeb(UART_UMR_SB_STOP_BITS_1, >umr);
 
/* Setting up BaudRate */
-   counter = (u32) ((gd->bus_clk / 32) + (gd->baudrate / 2));
-   counter = counter / gd->baudrate;
+   counter = (u32) ((gd->bus_clk / 32) + (baudrate / 2));
+   counter = counter / baudrate;
 
/* write to CTUR: divide counter upper byte */
-   uart->ubg1 = (u8) ((counter & 0xff00) >> 8);
+   writeb((u8)((counter & 0xff00) >> 8), >ubg1);
/* write to CTLR: divide counter lower byte */
-   uart->ubg2 = (u8) (counter & 0x00ff);
+   writeb((u8)(counter & 0x00ff), >ubg2);
 
-   uart->ucr = (UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED);
+   writeb(UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED, >ucr);
 
return (0);
 }
 
+static void mcf_serial_setbrg_common(uart_t *uart, int baudrate)
+{
+   u32 counter;
+
+   /* Setting up BaudRate */
+   counter = (u32) ((gd->bus_clk / 32) + (baudrate / 2));
+   counter = counter / baudrate;
+
+   /* write to CTUR: divide counter upper byte */
+   writeb(((counter & 0xff00) >> 8), >ubg1);
+   /* write to CTLR: divide counter lower byte */
+   writeb((counter & 0x00ff), >ubg2);
+
+   writeb(UART_UCR_RESET_RX, >ucr);
+   writeb(UART_UCR_RESET_TX, >ucr);
+
+   writeb(UART_UCR_RX_ENABLED | UART_UCR_TX_ENABLED, >ucr);
+}
+
+#ifndef CONFIG_DM_SERIAL
+
+static int mcf_serial_init(void)
+{
+   uart_t *uart_base;
+   int port_idx;
+
+   uart_base = (uart_t *)CONFIG_SYS_UART_BASE;
+   port_idx = CONFIG_SYS_UART_PORT;
+
+   return mcf_serial_init_common(uart_base, port_idx, gd->baudrate);
+}
+
 static void mcf_serial_putc(const char c)
 {
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   uart_t *uart = (uart_t *)CONFIG_SYS_UART_BASE;
 
if (c == '\n')
serial_putc('\r');
 
/* Wait for last character to go. */
-   while (!(uart->usr & UART_USR_TXRDY)) ;
+   while (!(readb(>usr) & UART_USR_TXRDY))
+   ;
 
-   uart->utb = c;
+   writeb(c, >utb);
 }
 
 static int mcf_serial_getc(void)
 {
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   uart_t *uart = (uart_t *)CONFIG_SYS_UART_BASE;
 
/* Wait for a character to arrive. */
-   while (!(uart->usr & UART_USR_RXRDY)) ;
-   return uart->urb;
-}
-
-static int mcf_serial_tstc(void)
-{
-   volatile uart_t *uart = (volatile uart_t *)(CONFIG_SYS_UART_BASE);
+   while (!(readb(>usr) & UART_USR_RXRDY))
+   ;
 
-   return (uart->usr & UART_USR_RXRDY);
+   return readb(>urb);
 }
 
 static void mcf_serial_setbrg(void)
 {
-   volatile uart_t *uart = 

[U-Boot] [PATCH v2 1/2] m68k: add malloc memory for early malloc

[Angelo Dureghello]

To use serial uclass and DM, CONFIG_SYS_MALLOC_F must be used.
So CONFIG_SYS_GENERIC_GLOBAL_DATA has been undefined and
call to board_init_f_mem() is added for all cpu's.

Signed-off-by: Angelo Dureghello 

---

Changes in v2: None

 arch/m68k/cpu/mcf5227x/start.S   | 8 
 arch/m68k/cpu/mcf523x/start.S| 8 
 arch/m68k/cpu/mcf52x2/start.S| 8 
 arch/m68k/cpu/mcf530x/cpu_init.c | 2 +-
 arch/m68k/cpu/mcf530x/start.S| 8 
 arch/m68k/cpu/mcf532x/start.S| 8 
 arch/m68k/cpu/mcf5445x/start.S   | 8 
 arch/m68k/cpu/mcf547x_8x/start.S | 8 
 arch/m68k/include/asm/config.h   | 2 --
 9 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/arch/m68k/cpu/mcf5227x/start.S b/arch/m68k/cpu/mcf5227x/start.S
index 23024f9..bcb5611 100644
--- a/arch/m68k/cpu/mcf5227x/start.S
+++ b/arch/m68k/cpu/mcf5227x/start.S
@@ -379,6 +379,14 @@ _start:
 
move.l #__got_start, %a5/* put relocation table address to a5 */
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
bsr cpu_init_f  /* run low-level CPU init code (from 
flash) */
bsr board_init_f/* run low-level board init code (from 
flash) */
 
diff --git a/arch/m68k/cpu/mcf523x/start.S b/arch/m68k/cpu/mcf523x/start.S
index 8a23e72..14b3025 100644
--- a/arch/m68k/cpu/mcf523x/start.S
+++ b/arch/m68k/cpu/mcf523x/start.S
@@ -141,6 +141,14 @@ _start:
 
move.l #__got_start, %a5/* put relocation table address to a5 */
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
bsr cpu_init_f  /* run low-level CPU init code (from 
flash) */
bsr board_init_f/* run low-level board init code (from 
flash) */
 
diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S
index 8a59496..abb9291 100644
--- a/arch/m68k/cpu/mcf52x2/start.S
+++ b/arch/m68k/cpu/mcf52x2/start.S
@@ -198,6 +198,14 @@ _after_flashbar_copy:
 
move.l #__got_start, %a5/* put relocation table address 
to a5 */
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
bsr cpu_init_f  /* run low-level CPU init code 
(from flash) */
bsr board_init_f/* run low-level board init 
code (from flash) */
 
diff --git a/arch/m68k/cpu/mcf530x/cpu_init.c b/arch/m68k/cpu/mcf530x/cpu_init.c
index 80dc239..b09eed8 100644
--- a/arch/m68k/cpu/mcf530x/cpu_init.c
+++ b/arch/m68k/cpu/mcf530x/cpu_init.c
@@ -142,7 +142,7 @@ int cpu_init_r(void)
return 0;
 }
 
-void uart_port_conf(void)
+void uart_port_conf(int port)
 {
 }
 
diff --git a/arch/m68k/cpu/mcf530x/start.S b/arch/m68k/cpu/mcf530x/start.S
index 097958a..d9034e1 100644
--- a/arch/m68k/cpu/mcf530x/start.S
+++ b/arch/m68k/cpu/mcf530x/start.S
@@ -137,6 +137,14 @@ _start:
/* put relocation table address to a5 */
move.l #__got_start, %a5
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
/* run low-level CPU init code (from flash) */
bsr cpu_init_f
 
diff --git a/arch/m68k/cpu/mcf532x/start.S b/arch/m68k/cpu/mcf532x/start.S
index 3b9ede0..98a5401 100644
--- a/arch/m68k/cpu/mcf532x/start.S
+++ b/arch/m68k/cpu/mcf532x/start.S
@@ -155,6 +155,14 @@ _start:
 
move.l #__got_start, %a5/* put relocation table address to a5 */
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
bsr cpu_init_f  /* run low-level CPU init code (from 
flash) */
bsr board_init_f/* run low-level board init code (from 
flash) */
 
diff --git a/arch/m68k/cpu/mcf5445x/start.S b/arch/m68k/cpu/mcf5445x/start.S
index 979eb5a..340ab84 100644
--- a/arch/m68k/cpu/mcf5445x/start.S
+++ b/arch/m68k/cpu/mcf5445x/start.S
@@ -664,6 +664,14 @@ _start:
 
move.l #__got_start, %a5/* put relocation table address to a5 */
 
+   /* Allocate and zero GD, update SP */
+   move.l  %sp,-(%sp)
+   bsr board_init_f_mem
+
+   /* Update stack- and frame-pointers */
+   move.l  %d0, %sp
+   move.l  %sp, %fp
+
bsr cpu_init_f  /* run low-level CPU init code (from 
flash) */
bsr board_init_f/* 

Re: [U-Boot] [PATCH 1/2] arm: imx6: Add DDR3 calibration code for MX6 Q/D/DL

[Eric Nelson]

Hi Marek,

On 12/16/2015 07:40 AM, Marek Vasut wrote:
> Add DDR3 calibration code for i.MX6Q, i.MX6D and i.MX6DL. This code
> fine-tunes the behavior of the MMDC controller in order to improve
> the signal integrity and memory stability.

It would be good to have a reference to AN4467 in the commit message,
since that document is the best reference to understanding this code:

http://cache.freescale.com/files/32bit/doc/app_note/AN4467.pdf

> 
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> ---
>  arch/arm/cpu/armv7/mx6/ddr.c| 559 
> 
>  arch/arm/include/asm/arch-mx6/mx6-ddr.h |   5 +
>  2 files changed, 564 insertions(+)
> 

Note that there's another implementation of this in the barebox
project:

http://git.pengutronix.de/?p=barebox.git;a=blob;f=arch/arm/mach-imx/imx6-mmdc.c;h=146df573e4eeed7132e93899b4b539e842bb6ba2;hb=HEAD

> diff --git a/arch/arm/cpu/armv7/mx6/ddr.c b/arch/arm/cpu/armv7/mx6/ddr.c
> index 6b039e4..194411f 100644
> --- a/arch/arm/cpu/armv7/mx6/ddr.c
> +++ b/arch/arm/cpu/armv7/mx6/ddr.c
> @@ -13,6 +13,565 @@
>  #include 
>  #include 
>  
> +#if defined(CONFIG_MX6QDL) || defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
> +

Should this use the common wait_for_bit?
http://lists.denx.de/pipermail/u-boot/2015-December/thread.html#237952

I'm not certain that the  handling is appropriate when
used here.

> +static int wait_for_bit(void *reg, const uint32_t mask, bool set)
> +{
> + unsigned int timeout = 1000;
> + u32 val;
> +
> + while (--timeout) {
> + val = readl(reg);
> + if (!set)
> + val = ~val;
> +
> + if ((val & mask) == mask)
> + return 0;
> +
> + udelay(1);
> + }
> +
> + printf("%s: Timeout (reg=%p mask=%08x wait_set=%i)\n",
> +   __func__, reg, mask, set);
> + hang(); /* DRAM couldn't be calibrated, game over :-( */
> +}
> +
> +static void reset_read_data_fifos(void)
> +{
> + struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
> +
> + /* Reset data FIFOs twice. */
> + setbits_le32(>mpdgctrl0, 1 << 31);
> + wait_for_bit(>mpdgctrl0, 1 << 31, 0);
> +
> + setbits_le32(>mpdgctrl0, 1 << 31);
> + wait_for_bit(>mpdgctrl0, 1 << 31, 0);
> +}
> +

See comments below about chip-selects during calibration.

> +static void precharge_all(const bool cs0_enable, const bool cs1_enable)
> +{
> + struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
> +
> + /*
> +  * Issue the Precharge-All command to the DDR device for both
> +  * chip selects. Note, CON_REQ bit should also remain set. If
> +  * only using one chip select, then precharge only the desired
> +  * chip select.
> +  */

AN4467 says that a wait for tRP is needed here, though none of the
other implementations explicitly do that.

The wait for CON_ACK seems like a good idea, though I wonder if
the waits shouldn't be performed **before** the commands are issued.

I'd also like to see a named constant for MDSCR_CON_ACK, and since
waiting for it is done in multiple places, perhaps wait_for_con_ack().

> + if (cs0_enable) { /* CS0 */
> + writel(0x04008050, >mdscr);
> + wait_for_bit(>mdscr, 1 << 14, 1);
> + }
> +
> + if (cs1_enable) { /* CS1 */
> + writel(0x04008058, >mdscr);
> + wait_for_bit(>mdscr, 1 << 14, 1);
> + }
> +}
> +
> +static void force_delay_measurement(int bus_size)
> +{
> + struct mmdc_p_regs *mmdc0 = (struct mmdc_p_regs *)MMDC_P0_BASE_ADDR;
> + struct mmdc_p_regs *mmdc1 = (struct mmdc_p_regs *)MMDC_P1_BASE_ADDR;
> +
> + writel(0x800, >mpmur0);
> + if (bus_size == 0x2)
> + writel(0x800, >mpmur0);
> +}
> +
> +static void modify_dg_result(u32 *reg_st0, u32 *reg_st1, u32 *reg_ctrl)
> +{
> + u32 dg_tmp_val, dg_dl_abs_offset, dg_hc_del, val_ctrl;
> +
> + /*
> +  * DQS gating absolute offset should be modified from reflecting
> +  * (HW_DG_LOWx + HW_DG_UPx)/2 to reflecting (HW_DG_UPx - 0x80)
> +  */
> +
> + val_ctrl = readl(reg_ctrl);
> + val_ctrl &= 0xf000;
> +

Though this matches the app note and other implementations, I think
this would be easier to understand by shifting first and anding with
0x7ff.

> + dg_tmp_val = ((readl(reg_st0) & 0x07ff) >> 16) - 0xc0;

Especially since these calculations operate on the shifted values:

> + dg_dl_abs_offset = dg_tmp_val & 0x7f;
> + dg_hc_del = (dg_tmp_val & 0x780) << 1;
> +
> + val_ctrl |= dg_dl_abs_offset + dg_hc_del;
> +
> + dg_tmp_val = ((readl(reg_st1) & 0x07ff) >> 16) - 0xc0;
> + dg_dl_abs_offset = dg_tmp_val & 0x7f;
> + dg_hc_del = (dg_tmp_val & 0x780) << 1;
> +
> + val_ctrl |= (dg_dl_abs_offset + dg_hc_del) << 16;
> +
> + writel(val_ctrl, reg_ctrl);
> +}
> +

I'd recommend passing parameters of mx6_ddr_sysinfo (input) and

Re: [U-Boot] [PATCH 2/2] arm: imx6: Enable DDR calibration on Novena

[Eric Nelson]

Hi Marek,

On 12/16/2015 07:40 AM, Marek Vasut wrote:
> Enable the DDR calibration functionality on Novena to deal with the
> memory SoDIMM on this board.

Shouldn't this be in two patches?

> Moreover, tweak the initial DDR DRAM parameters so the
> calibration works properly.
>
> Signed-off-by: Marek Vasut 
> ---
>  board/kosagi/novena/novena_spl.c | 23 ++-
>  1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/board/kosagi/novena/novena_spl.c
b/board/kosagi/novena/novena_spl.c
> index eb46265..f779bb4 100644
> --- a/board/kosagi/novena/novena_spl.c
> +++ b/board/kosagi/novena/novena_spl.c
> @@ -434,8 +434,8 @@ static struct mx6dq_iomux_ddr_regs
novena_ddr_ioregs = {
>   .dram_ras   = 0x0038,
>   .dram_reset = 0x0038,
>   /* SDCKE[0:1]: 100k pull-up */
> - .dram_sdcke0= 0x3000,
> - .dram_sdcke1= 0x3000,
> + .dram_sdcke0= 0x0038,
> + .dram_sdcke1= 0x0038,
>   /* SDBA2: pull-up disabled */
>   .dram_sdba2 = 0x,
>   /* SDODT[0:1]: 100k pull-up, 40 ohm */
> @@ -512,10 +512,10 @@ static struct mx6_ddr_sysinfo novena_ddr_info = {
>   /* Single chip select */
>   .ncs= 1,
>   .cs1_mirror = 0,
> - .rtt_wr = 1,/* RTT_Wr = RZQ/4 */
> - .rtt_nom= 2,/* RTT_Nom = RZQ/2 */
> - .walat  = 3,/* Write additional latency */
> - .ralat  = 7,/* Read additional latency */
> + .rtt_wr = 0,/* RTT_Wr = RZQ/4 */
> + .rtt_nom= 1,/* RTT_Nom = RZQ/2 */
> + .walat  = 0,/* Write additional latency */
> + .ralat  = 5,/* Read additional latency */
>   .mif3_mode  = 3,/* Command prediction working mode */
>   .bi_on  = 1,/* Bank interleaving enabled */
>   .sde_to_rst = 0x10, /* 14 cycles, 200us (JEDEC default) */
> @@ -530,9 +530,9 @@ static struct mx6_ddr3_cfg elpida_4gib_1600 = {
>   .rowaddr= 16,
>   .coladdr= 10,
>   .pagesz = 2,
> - .trcd   = 1300,
> - .trcmin = 4900,
> - .trasmin= 3590,
> + .trcd   = 1375,
> + .trcmin = 4875,
> + .trasmin= 3500,
>  };
>
>  static void ccgr_init(void)
> @@ -601,6 +601,11 @@ void board_init_f(ulong dummy)
>   mx6dq_dram_iocfg(64, _ddr_ioregs, _grp_ioregs);
>   mx6_dram_cfg(_ddr_info, _mmdc_calib, _4gib_1600);
>
> + /* Perform DDR DRAM calibration */
> + udelay(100);

Shouldn't the return values be tested?

> + mmdc_do_write_level_calibration();
> + mmdc_do_dqs_calibration();
> +
>   /* Clear the BSS. */
>   memset(__bss_start, 0, __bss_end - __bss_start);
>
>

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

Re: [U-Boot] [PATCH 0/4] Add a new poweroff command and implement it for sunxi

[Ian Campbell]

On Sun, 2015-12-20 at 16:41 +0100, Hans de Goede wrote:
> Hi All,
> 
> I've had this idea that it would be good to have a poweroff command in
> u-boot in my head for a while now. The reason being that during u-boot
> development one often stays in just u-boot (e.g. when testing usb kbd
> support), when I'm then done testing having a poweroff command would
> be useful, esp. on devices with builtin batteries like tablets where
> one cannot just pull the powerplug.

Patches #2..#4: Acked-by: Ian Campbell 

#1 looks fine to me too, modulo Tom's comments.

Ian.

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

Re: [U-Boot] [PATCH] sun5i: Add defconfig and dts file for the Empire Electronix D709 tablet

[Ian Campbell]

On Sun, 2015-12-20 at 12:44 +0100, Hans de Goede wrote:
> The Empire Electronix D709 tablet is a fairly standard 7" A13 tablet,
> featuring usb-wifi, a micro-sd slot, micro-usb otg and headphone
> jack.
> 
> Empire Electronix is written on the back of the tablet, the D709
> model
> info can be found in the about tablet menu in android.
> 
> The PCB has no markings to speak of.
> 
> This dts file is identical to the one submitted to the upstream
> kernel.
> 
> Signed-off-by: Hans de Goede 

Acked-by: Ian Campbell 

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

[U-Boot] [PATCH] sunxi: Add CONFIG_SUNXI_NO_PMIC to Marsboard A10 config

[Aleksei Mamlin]

Marsboard A10 haven't any PMIC at all, so add CONFIG_SUNXI_NO_PMIC=y to
Marsboard_A10_defconfig

Signed-off-by: Aleksei Mamlin 
---
 configs/Marsboard_A10_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/Marsboard_A10_defconfig b/configs/Marsboard_A10_defconfig
index 5689cff..806fb64 100644
--- a/configs/Marsboard_A10_defconfig
+++ b/configs/Marsboard_A10_defconfig
@@ -9,4 +9,5 @@ CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,AHCI"
 # CONFIG_CMD_FLASH is not set
 # CONFIG_CMD_FPGA is not set
 CONFIG_CMD_GPIO=y
+CONFIG_SUNXI_NO_PMIC=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.4.10

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