Re: [U-Boot] [PATCH][RE-SUBMIT] usb: gadget: dwc2_udc_otg: modified the check condition for max packet size of ep_in in high speed

[Marek Vasut]

On Wednesday, January 27, 2016 at 09:39:40 PM, Steve Rae wrote:
> From: Frank Wang 
> 
> In current high speed fastboot, fs_ep_in.wMaxPacketSize is configured 64
> bytes as default, as a result, it failed to match the size at
> initialization stage in usb controller.
> Actually, hardware can support less than or equal to 512 bytes in high
> speed mode, so I changed the condition from  '!=' to '>' to fix this
> issue.
> 
> Signed-off-by: Frank Wang 
> Tested-by: Steve Rae 
> ---

Applied, thanks.

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

Re: [U-Boot] [PATCH 2/2] net: phy: micrel: fix divisor value for KSZ9031 phy skew

[Marek Vasut]

On Wednesday, January 27, 2016 at 10:46:00 PM, dingu...@opensource.altera.com 
wrote:
> From: Dinh Nguyen 
> 
> The picoseconds to register value divisor(ps_to_regval) should be 60 and
> not 200. Linux has KSZ9031_PS_TO_REG defined to be 60 as well. 60 is the
> correct divisor because the 4-bit skew values are defined from
> 0x(-420ps) to 0x(480ps), increments of 60.
> 
> For example, a DTS skew value of 420, represents 0ps delay, which should be
> 0x7. With the previous divisor of 200, it would result in 0x2, which
> represents a -300ps delay.
> 
> With this patch, ethernet on the SoCFPGA DE0 Atlas is now able to work with
> 1Gb ethernet.
> 
> References:
> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf -> page 26
> 
> Signed-off-by: Dinh Nguyen 

This is fine, thanks for spotting it.

Acked-by: Marek Vasut 

Joe, will you pick these two and push for 2016.03 or shall I pick them ?

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

Re: [U-Boot] [PATCH 2/2] net: phy: micrel: fix divisor value for KSZ9031 phy skew

[Marek Vasut]

On Wednesday, January 27, 2016 at 11:53:29 PM, Joe Hershberger wrote:
> Hi Marek,
> 
> On Wed, Jan 27, 2016 at 4:07 PM, Marek Vasut  wrote:
> > On Wednesday, January 27, 2016 at 10:46:00 PM,
> > dingu...@opensource.altera.com
> > 
> > wrote:
> >> From: Dinh Nguyen 
> >> 
> >> The picoseconds to register value divisor(ps_to_regval) should be 60 and
> >> not 200. Linux has KSZ9031_PS_TO_REG defined to be 60 as well. 60 is the
> >> correct divisor because the 4-bit skew values are defined from
> >> 0x(-420ps) to 0x(480ps), increments of 60.
> >> 
> >> For example, a DTS skew value of 420, represents 0ps delay, which should
> >> be 0x7. With the previous divisor of 200, it would result in 0x2, which
> >> represents a -300ps delay.
> >> 
> >> With this patch, ethernet on the SoCFPGA DE0 Atlas is now able to work
> >> with 1Gb ethernet.
> >> 
> >> References:
> >> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf -> page 26
> >> 
> >> Signed-off-by: Dinh Nguyen 
> > 
> > This is fine, thanks for spotting it.
> > 
> > Acked-by: Marek Vasut 
> > 
> > Joe, will you pick these two and push for 2016.03 or shall I pick them ?
> 
> I'll get them.

Roger, thanks!

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini  wrote:
> On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:
>> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> >> Hi Tom,
>> >>
>> >> I'm playing with the idea of including the patchwork patch ID in the
>> >> commit message of each commit that I apply to provide better
>> >> cross-reference ability.
>> >>
>> >> * Access to comments on patches
>> >> * Clarity on exactly which version of a patch was applied
>> >> * No need to search by patch subject
>> >>
>> >> Here is an example in a working branch:
>> >>
>> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>> >
>> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>>
>> Would it be more or less compelling if it had a format similar this?
>>
>> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>
> Yes.

Are you being funny (more and less == not)? Or did you miss-read? :)

>> >> What do you (or anyone else) think?
>> >
>> > Well, I'm not a super fan of it.  For your second point, this is why I
>> > use bundles, mutt and a macro.  For the other points, at least I find
>> > google does a good job pulling up the right patch at least.
>>
>> Bundles seem awkward. Perhaps I'm just not using them effectively.
>> What benefit do they give you? How are they part of your workflow?
>
> OK, I'm going to delete this in a few days but here's my bundle for the

Doesn't that mean it will very soon not be traceable exactly which
patch version was applied? What I was proposing would mean that the
commit message could continue to refer back to the patch even if
archived.

> last import I did:
> https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> My flow is:
> 1) Assign all unassigned patches
> 2) Open my todo list in patchwork
> 3) Create a bundle with all of the patches I want based on my critera at
> the time.
> 4) Download bundle as mbox, git am -3 it, get big build going.
> 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> at first
> 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> each email group reply, run macro to insert applied message, postponed
> 7) Check output from big build, assuming good results, push and spam out
> all of my queued messages.

Gotcha. Thanks!

I'm trying to improve my workflow now, and this Patch tag was
something that came out of it. It's not required for the workflow, but
it is free to do within it. It has the potential to slightly simplify
one possible workflow, so no big deal.

If people think it will be simply noise, I'll leave it out.

I think this may speed up cross-referencing. Seemed like a good thing.

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

Re: [U-Boot] [PATCH 2/2] net: phy: micrel: fix divisor value for KSZ9031 phy skew

[Måns Rullgård]

 writes:

> From: Dinh Nguyen 
>
> The picoseconds to register value divisor(ps_to_regval) should be 60 and not
> 200. Linux has KSZ9031_PS_TO_REG defined to be 60 as well. 60 is the correct
> divisor because the 4-bit skew values are defined from 0x(-420ps) to
> 0x(480ps), increments of 60.
>
> For example, a DTS skew value of 420, represents 0ps delay, which should be 
> 0x7.
> With the previous divisor of 200, it would result in 0x2, which represents a
> -300ps delay.
>
> With this patch, ethernet on the SoCFPGA DE0 Atlas is now able to work with
> 1Gb ethernet.

Is this expected to make any difference on the Altera socdk?  Both with
and without the patch, it takes a very long time (sometimes minutes) to
negotiate a link, but once it does it works fine.

> References:
> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf -> page 26
>
> Signed-off-by: Dinh Nguyen 
> ---
>  drivers/net/phy/micrel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 19b6bc7..2530a5b 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -211,7 +211,7 @@ static int ksz90x1_of_config_group(struct phy_device 
> *phydev,
>  {
>   struct udevice *dev = phydev->dev;
>   struct phy_driver *drv = phydev->drv;
> - const int ps_to_regval = 200;
> + const int ps_to_regval = 60;
>   int val[4];
>   int i, changed = 0, offset, max;
>   u16 regval = 0;
> -- 
> 2.6.2

-- 
Måns Rullgård
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: serial_stm32: move clock config from driver to board

[Vikas MANOCHA]

Hi Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Wednesday, January 27, 2016 2:54 PM
> To: Vikas MANOCHA
> Cc: Albert ARIBAUD; Kamil Lulko; U-Boot Mailing List; Peter Griffin; Antonio
> Borneo; re...@wp.pl; kunhuahuang
> Subject: Re: [PATCH] serial: serial_stm32: move clock config from driver to
> board
> 
> On 26 January 2016 at 19:12, Vikas Manocha 
> wrote:
> > This patch removes the uart clock enable from serial driver & move it
> > in the board code.
> >
> > Signed-off-by: Vikas Manocha 
> > ---
> >  arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 15 
> >  arch/arm/include/asm/arch-stm32f4/stm32_periph.h   | 27
> +++
> >  arch/arm/mach-stm32/stm32f4/clock.c| 20 +++
> >  board/st/stm32f429-discovery/stm32f429-discovery.c |  3 ++
> >  drivers/serial/serial_stm32.c  | 40 
> > --
> >  5 files changed, 65 insertions(+), 40 deletions(-)  create mode
> > 100644 arch/arm/include/asm/arch-stm32f4/stm32_defs.h
> >  create mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_periph.h
> 
> Reviewed-by: Simon Glass 

Thanks for reviewing.

> 
> You might consider adding a clock driver.

Yes, I agree. After some cleanup, I am planning to add support for clock and 
pinmux driver.

Rgds,
Vikas

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

[U-Boot] [PATCH 2/3] mips: ath79: Drop SYS_MIPS_CACHE_INIT_RAM_LOAD

[Marek Vasut]

Drop SYS_MIPS_CACHE_INIT_RAM_LOAD from the Kconfig, since this option
is bogus. The DRAM is not active when this option comes into play, so
any attempt to restore valid cache state from invalid DRAM must fail.
Disable this option to prevent such failure and potential undefined
behavior.

Signed-off-by: Marek Vasut 
Cc: Daniel Schwierzeck 
Cc: Wills Wang 
---
 arch/mips/mach-ath79/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/mach-ath79/Kconfig b/arch/mips/mach-ath79/Kconfig
index f61efd2..95f7de9 100644
--- a/arch/mips/mach-ath79/Kconfig
+++ b/arch/mips/mach-ath79/Kconfig
@@ -12,7 +12,6 @@ config SOC_AR933X
select SUPPORTS_BIG_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
select SUPPORTS_CPU_MIPS32_R2
-   select SYS_MIPS_CACHE_INIT_RAM_LOAD
select MIPS_TUNE_24KC
help
  This supports QCA/Atheros ar933x family SOCs.
@@ -22,7 +21,6 @@ config SOC_QCA953X
select SUPPORTS_BIG_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
select SUPPORTS_CPU_MIPS32_R2
-   select SYS_MIPS_CACHE_INIT_RAM_LOAD
select MIPS_TUNE_24KC
help
  This supports QCA/Atheros qca953x family SOCs.
-- 
2.1.4

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

[U-Boot] [PATCH 3/3] mips: ath79: Move SYS_SOC and SYS_VENDOR to board Kconfig

[Marek Vasut]

In order to support boards with ath79 from different vendors and
thus located under /board/$VENDOR/ , we need to define SYS_VENDOR
and SYS_SOC in the board-level Kconfig. Move these two variables
into board-level Kconfig for both ap121 and ap143 boards.

Signed-off-by: Marek Vasut 
Cc: Daniel Schwierzeck 
Cc: Wills Wang 
---
 arch/mips/mach-ath79/Kconfig | 6 --
 board/ath79/ap121/Kconfig| 6 ++
 board/ath79/ap143/Kconfig| 6 ++
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/mips/mach-ath79/Kconfig b/arch/mips/mach-ath79/Kconfig
index 95f7de9..8f07a77 100644
--- a/arch/mips/mach-ath79/Kconfig
+++ b/arch/mips/mach-ath79/Kconfig
@@ -1,12 +1,6 @@
 menu "QCA/Athroes 7xxx/9xxx platforms"
depends on ARCH_ATH79
 
-config SYS_VENDOR
-   default "ath79"
-
-config SYS_SOC
-   default "ath79"
-
 config SOC_AR933X
bool
select SUPPORTS_BIG_ENDIAN
diff --git a/board/ath79/ap121/Kconfig b/board/ath79/ap121/Kconfig
index ec72914..a4e5690 100644
--- a/board/ath79/ap121/Kconfig
+++ b/board/ath79/ap121/Kconfig
@@ -1,5 +1,11 @@
 if BOARD_AP121
 
+config SYS_VENDOR
+   default "ath79"
+
+config SYS_SOC
+   default "ath79"
+
 config SYS_BOARD
default "ap121"
 
diff --git a/board/ath79/ap143/Kconfig b/board/ath79/ap143/Kconfig
index 118b9b5..2e54fa7 100644
--- a/board/ath79/ap143/Kconfig
+++ b/board/ath79/ap143/Kconfig
@@ -1,5 +1,11 @@
 if BOARD_AP143
 
+config SYS_VENDOR
+   default "ath79"
+
+config SYS_SOC
+   default "ath79"
+
 config SYS_BOARD
default "ap143"
 
-- 
2.1.4

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

[U-Boot] [PATCH] implement Fastboot via USB OTG on bcm28155_ap boards

[Steve Rae]

Don't understand how it happened, but this change got applied twice!
Therefore, removing the duplicated items.

Signed-off-by: Steve Rae 
---

 include/configs/bcm28155_ap.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/include/configs/bcm28155_ap.h b/include/configs/bcm28155_ap.h
index a257084..c9515a8 100644
--- a/include/configs/bcm28155_ap.h
+++ b/include/configs/bcm28155_ap.h
@@ -130,7 +130,6 @@
 #define CONFIG_CMD_BOOTZ
 #define CONFIG_FAT_WRITE
 
-
 /* Fastboot and USB OTG */
 #define CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
@@ -150,23 +149,4 @@
 #define CONFIG_G_DNL_PRODUCT_NUM   0x0d02  /* nexus one */
 #define CONFIG_G_DNL_MANUFACTURER  "Broadcom Corporation"
 
-/* Fastboot and USB OTG */
-#define CONFIG_USB_FUNCTION_FASTBOOT
-#define CONFIG_CMD_FASTBOOT
-#define CONFIG_FASTBOOT_FLASH
-#define CONFIG_FASTBOOT_FLASH_MMC_DEV  0
-#define CONFIG_SYS_CACHELINE_SIZE  64
-#define CONFIG_USB_FASTBOOT_BUF_SIZE   (CONFIG_SYS_SDRAM_SIZE - SZ_1M)
-#define CONFIG_USB_FASTBOOT_BUF_ADDR   CONFIG_SYS_SDRAM_BASE
-#define CONFIG_USB_GADGET
-#define CONFIG_USB_GADGET_DUALSPEED
-#define CONFIG_USB_GADGET_VBUS_DRAW0
-#define CONFIG_USB_GADGET_S3C_UDC_OTG
-#define CONFIG_USB_GADGET_BCM_UDC_OTG_PHY
-#define CONFIG_USB_GADGET_DOWNLOAD
-#define CONFIG_USBID_ADDR  0x34052c46
-#define CONFIG_G_DNL_VENDOR_NUM0x18d1  /* google */
-#define CONFIG_G_DNL_PRODUCT_NUM   0x0d02  /* nexus one */
-#define CONFIG_G_DNL_MANUFACTURER  "Broadcom Corporation"
-
 #endif /* __BCM28155_AP_H */
-- 
1.8.5

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Joe Hershberger]

On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:
> On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> Hi Tom,
>>
>> I'm playing with the idea of including the patchwork patch ID in the
>> commit message of each commit that I apply to provide better
>> cross-reference ability.
>>
>> * Access to comments on patches
>> * Clarity on exactly which version of a patch was applied
>> * No need to search by patch subject
>>
>> Here is an example in a working branch:
>>
>> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>
> I'd prfer Patchwork or Patchwork-ID or something not just Patch.

Would it be more or less compelling if it had a format similar this?

Patchwork: https://patchwork.ozlabs.org/patch/571773/

>
>>
>> What do you (or anyone else) think?
>
> Well, I'm not a super fan of it.  For your second point, this is why I
> use bundles, mutt and a macro.  For the other points, at least I find
> google does a good job pulling up the right patch at least.

Bundles seem awkward. Perhaps I'm just not using them effectively.
What benefit do they give you? How are they part of your workflow?

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

[U-Boot] [PATCH 1/3] mips: ath79: Fix compiler warning on const assignment

[Marek Vasut]

The assignment const T var; var = value; is illegal, since var is
constant. Drop the const to fix the compiler warning.

Signed-off-by: Marek Vasut 
Cc: Daniel Schwierzeck 
Cc: Wills Wang 
---
 arch/mips/mach-ath79/reset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/mach-ath79/reset.c b/arch/mips/mach-ath79/reset.c
index 504b833..e8f5796 100644
--- a/arch/mips/mach-ath79/reset.c
+++ b/arch/mips/mach-ath79/reset.c
@@ -46,7 +46,7 @@ void _machine_restart(void)
 
 u32 get_bootstrap(void)
 {
-   const void __iomem *base;
+   void __iomem *base;
u32 reg = 0;
 
base = map_physmem(AR71XX_RESET_BASE, AR71XX_RESET_SIZE,
-- 
2.1.4

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

[U-Boot] SPL loading U-Boot from a FIT

[Simon Glass]

Hi,

(moving to a new thread)

Tom mentioned:

>We _really_ need some way to support more than one board per binary
>before we can move everything to DM only.

We discussed this on IRC but since that doesn't exist as far as the
mailing list is concerned...

The current plan is:

- Adjust build system to optionally build a u-boot.img in FIT format
that includes the U-Boot binary and >1 device tree files
- Adjust SPL to load this
- Add a way for SPL to determine which device tree to select (by
calling a board-specific function)
- Have SPL pass this selected device tree to U-Boot when it starts

Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.

I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.

If you are interested in taking a look before patches are ready, see
u-boot-fdt/spl-working.

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

Re: [U-Boot] [PATCH 2/2] hush: Add rudimentary support for PS1 and PS2

[Simon Glass]

On 26 January 2016 at 20:47, Marek Vasut  wrote:
> Add trivial support for changing the U-Boot command prompt string
> by setting PS1 and PS2 environment variables. Only static variables
> are supported.
>
> Signed-off-by: Marek Vasut 
> ---
>  README|  8 
>  common/cli_hush.c | 10 ++
>  2 files changed, 18 insertions(+)
>

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

Re: [U-Boot] patman dies cryptially when a (valid) e-mail address contains parentheses (or is UTF-8)

[Simon Glass]

Hi Albert,

On 27 January 2016 at 01:22, Albert ARIBAUD  wrote:
> Hello Simon,
>
> I just noticed this while adding a Series-cc to my work address which
> has parentheses: running patman (without -n) will result in
>
> sh: 1: Syntax error: "(" unexpected
>
> Which initially left me wondering what was happening until I realized
> one of the Series-cc addresses had parentheses, e.g.
>
> Series-cc: "Name NAME (NAME)" 
>
> Note that the parentheses were in the free-form part of the address,
> itself within double quotation marks, which appears valid wrt the RFC.
>
> I've tried using single quotes as a workaround:
>
> Series-cc: 'Name NAME (NAME)' 
>
> It kind-of-works in that patman does not die, but the resulting address
> in the mail has outer double quotes and inner single quotes, e.g.
>
> "'Name NAME (NAME)'" 
>
> Aditionally, addresses with names in UTF-8 also fail, though
> differently but still with a message somewhat unrelated to the actual
> cause (UTF-8-name is the placeholder for a name containing UTF-8
> diacritics):
>
> fatal: ambiguous argument 'UTF-8-name ':
> unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
>
> The same single-quote hack works it around, with the resulting
> mail Cc:ing the name surrounded by single quotes only:
>
> Cc: 'UTF-8-name' 
>
> Cc:ing Marek who is a die-hard fan of UTF-8 names in e-mail
> addresses. :)

I wonder if this is a problem with the cc_cmd code in patman.py?

# Called from git with a patch filename as argument
# Printout a list of additional CC recipients for this patch
elif options.cc_cmd:

Perhaps it should quote its output somehow?

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

Re: [U-Boot] [PATCH] x86: Correct spi node alias

[Simon Glass]

On 27 January 2016 at 01:56, Bin Meng  wrote:
> With recent changes spi node was moved to a place as a subnode under
> pch, so update the alias to refer to its correct place as well.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/bayleybay.dts  | 4 ++--
>  arch/x86/dts/broadwell_som-6896.dts | 4 ++--
>  arch/x86/dts/chromebook_link.dts| 4 ++--
>  arch/x86/dts/chromebox_panther.dts  | 4 ++--
>  arch/x86/dts/crownbay.dts   | 4 ++--
>  arch/x86/dts/galileo.dts| 4 ++--
>  arch/x86/dts/minnowmax.dts  | 4 ++--
>  7 files changed, 14 insertions(+), 14 deletions(-)

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini  wrote:
> > On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> >> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:
> >> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >> >> Hi Tom,
> >> >>
> >> >> I'm playing with the idea of including the patchwork patch ID in the
> >> >> commit message of each commit that I apply to provide better
> >> >> cross-reference ability.
> >> >>
> >> >> * Access to comments on patches
> >> >> * Clarity on exactly which version of a patch was applied
> >> >> * No need to search by patch subject
> >> >>
> >> >> Here is an example in a working branch:
> >> >>
> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >> >
> >> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> >>
> >> Would it be more or less compelling if it had a format similar this?
> >>
> >> Patchwork: https://patchwork.ozlabs.org/patch/571773/
> >
> > Yes.
> 
> Are you being funny (more and less == not)? Or did you miss-read? :)

Oops, yes, misread, yes, I like that.

> >> >> What do you (or anyone else) think?
> >> >
> >> > Well, I'm not a super fan of it.  For your second point, this is why I
> >> > use bundles, mutt and a macro.  For the other points, at least I find
> >> > google does a good job pulling up the right patch at least.
> >>
> >> Bundles seem awkward. Perhaps I'm just not using them effectively.
> >> What benefit do they give you? How are they part of your workflow?
> >
> > OK, I'm going to delete this in a few days but here's my bundle for the
> 
> Doesn't that mean it will very soon not be traceable exactly which
> patch version was applied? What I was proposing would mean that the
> commit message could continue to refer back to the patch even if
> archived.

It means the the link I gave for the bundle will be gone.  The patches
will be there, but I will also move them from Under Review to Accepted.

> > last import I did:
> > https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
> > My flow is:
> > 1) Assign all unassigned patches
> > 2) Open my todo list in patchwork
> > 3) Create a bundle with all of the patches I want based on my critera at
> > the time.
> > 4) Download bundle as mbox, git am -3 it, get big build going.
> > 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
> > at first
> > 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
> > each email group reply, run macro to insert applied message, postponed
> > 7) Check output from big build, assuming good results, push and spam out
> > all of my queued messages.
> 
> Gotcha. Thanks!
> 
> I'm trying to improve my workflow now, and this Patch tag was
> something that came out of it. It's not required for the workflow, but
> it is free to do within it. It has the potential to slightly simplify
> one possible workflow, so no big deal.
> 
> If people think it will be simply noise, I'll leave it out.
> 
> I think this may speed up cross-referencing. Seemed like a good thing.

My concern is that since it's not injected by patchwork already I would
have to add it to each commit.  Today, unless I need to either make
something apply or do a minor fixup to the contents, I don't modify any
commit message, so my git am is it.

-- 
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] fastboot: update error and warning messages

[Marek Vasut]

On Thursday, January 28, 2016 at 12:02:41 AM, Steve Rae wrote:
> Fix the formatting in error messages, and demote one error message
> to a warning, as it is only informational.
> 
> Signed-off-by: Steve Rae 

I'd leave this to Lukasz, if he doesn't respond, ping me in a week or so.

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

[U-Boot] [PATCH] [RFC] net: Add ag7xxx driver for Atheros MIPS

[Marek Vasut]

Add ethernet driver for the AR71xx and AR9xxx Atheros MIPS machines.

Signed-off-by: Marek Vasut 
Cc: Daniel Schwierzeck 
Cc: Joe Hershberger 
Cc: Wills Wang 
---
 arch/mips/dts/ap121.dts|   8 +
 arch/mips/dts/ar933x.dtsi  |  16 +
 arch/mips/mach-ath79/cpu.c |  47 +++
 configs/ap121_defconfig|   1 +
 drivers/net/Kconfig|   9 +
 drivers/net/Makefile   |   1 +
 drivers/net/ag7xxx.c   | 794 +
 7 files changed, 876 insertions(+)
 create mode 100644 drivers/net/ag7xxx.c

NOTE: This is RFC patch, it is by no means a standard submission, but it should
  give you some starting point for the ethernet driver.
NOTE: The driver works and I can transfer data via TFTP, but this patch needs
  splitting and cleanup. Some FIXMEs need to be sorted out of course.
NOTE: This is only tested on ar9331.

diff --git a/arch/mips/dts/ap121.dts b/arch/mips/dts/ap121.dts
index 00bdd8b..337ae8f 100644
--- a/arch/mips/dts/ap121.dts
+++ b/arch/mips/dts/ap121.dts
@@ -21,6 +21,14 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
clock-frequency = <2500>;
 };
diff --git a/arch/mips/dts/ar933x.dtsi b/arch/mips/dts/ar933x.dtsi
index a75e173..f71a31f 100644
--- a/arch/mips/dts/ar933x.dtsi
+++ b/arch/mips/dts/ar933x.dtsi
@@ -62,6 +62,22 @@
 
status = "disabled";
};
+
+   gmac0: eth@0x1900 {
+   compatible = "qca,ag7240-mac";
+   reg = <0x1900 0x200>;
+   phy-mode = "rmii";
+
+   status = "disabled";
+   };
+
+   gmac1: eth@0x1a00 {
+   compatible = "qca,ag7240-mac";
+   reg = <0x1a00 0x200>;
+   phy-mode = "rgmii";
+
+   status = "disabled";
+   };
};
 
spi0: spi@1f00 {
diff --git a/arch/mips/mach-ath79/cpu.c b/arch/mips/mach-ath79/cpu.c
index d8910a0..3b41a90 100644
--- a/arch/mips/mach-ath79/cpu.c
+++ b/arch/mips/mach-ath79/cpu.c
@@ -201,3 +201,50 @@ int print_cpuinfo(void)
 
return 0;
 }
+
+/*
+ * Un-reset ethernet. DM still doesn't have any notion of reset
+ * framework, so we do it by hand here.
+ */
+#define AR7240_RESET   0xb806001c
+#define AR7240_BOOTSTRAP_STATUS0xb80600ac
+#define AR7240_S26_CLK_CTRL_OFFSET 0xb8050024
+
+#define AR7240_RESET_GE1_PHY   BIT(/*23*/12)
+#define AR7240_RESET_GE0_PHY   BIT(/*22*/8)
+#define AR7240_RESET_GE1_MAC   BIT(13)
+#define AR7240_RESET_GE0_MAC   BIT(9)
+
+int cpu_eth_init(bd_t *bis)
+{
+   /* Clear MDIO slave mask */
+   clrbits_be32((void *)AR7240_BOOTSTRAP_STATUS, 0x0002);
+
+   mdelay(10);
+
+   /* Get Atheros S26 PHY out of reset */
+   clrsetbits_be32((void *)AR7240_S26_CLK_CTRL_OFFSET, 0x1f, 0x10);
+
+   mdelay(10);
+
+   setbits_be32((void *)AR7240_RESET,
+AR7240_RESET_GE0_MAC | AR7240_RESET_GE0_PHY |
+AR7240_RESET_GE1_MAC | AR7240_RESET_GE1_PHY);
+
+   mdelay(10);
+
+   clrbits_be32((void *)AR7240_RESET,
+AR7240_RESET_GE0_MAC | AR7240_RESET_GE0_PHY |
+AR7240_RESET_GE1_MAC | AR7240_RESET_GE1_PHY);
+
+   mdelay(10);
+
+   /* We support S26 PHY only */
+/* reg = readl((void *)priv->gmac_reg + AG7XXX_GMAC_ETH_CFG);
+   reg &= ~(0x3 << 3);
+   reg |= AG7XXX_ETH_CFG_MII_GE0_SLAVE;
+   writel(reg, (void *)priv->gmac_reg + AG7XXX_GMAC_ETH_CFG);
+*/
+
+   return 0;
+}
diff --git a/configs/ap121_defconfig b/configs/ap121_defconfig
index 0e2c7e8..7b76429 100644
--- a/configs/ap121_defconfig
+++ b/configs/ap121_defconfig
@@ -29,6 +29,7 @@ CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
+CONFIG_AG7XXX=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_WINBOND=y
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index de54ca8..5a5a954 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -25,6 +25,15 @@ menuconfig NETDEVICES
 
 if NETDEVICES
 
+config AG7XXX
+   bool "Atheros AG7xxx Ethernet MAC support"
+   depends on DM_ETH
+   select PHYLIB
+   help
+ This driver supports the Atheros AG7xxx Ethernet MAC. This MAC is
+ present in the Atheros AR7xxx, AR9xxx and QCA9xxx MIPS chips.
+
+
 config ALTERA_TSE
bool "Altera Triple-Speed Ethernet MAC support"
depends on DM_ETH
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 150470c..384735a 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -7,6 +7,7 @@
 
 obj-$(CONFIG_PPC4xx_EMAC) 

Re: [U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> I'm playing with the idea of including the patchwork patch ID in the
> commit message of each commit that I apply to provide better
> cross-reference ability.
> 
> * Access to comments on patches
> * Clarity on exactly which version of a patch was applied
> * No need to search by patch subject
> 
> Here is an example in a working branch:
> 
> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a

I'd prfer Patchwork or Patchwork-ID or something not just Patch.

> 
> What do you (or anyone else) think?

Well, I'm not a super fan of it.  For your second point, this is why I
use bundles, mutt and a macro.  For the other points, at least I find
google does a good job pulling up the right patch at least.

-- 
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 1/2] net: phy: micrel: add documentation for Micrel KSZ90x1 binding

[Joe Hershberger]

On Wed, Jan 27, 2016 at 3:45 PM,   wrote:
> From: Dinh Nguyen 
>
> Add the DTS documentation for the Micrel KSZ90x1 binding.
>
> The original document was from:
> [commit 4b405efbe12de28b26289282b431323d73992381 from the Linux kernel]
>
> This takes the original document and adds a clarification on how the skew
> values are represented in the code.
>
> References:
>
> Micrel ksz9021rl/rn Data Sheet, Revision 1.2. Dated 2/13/2014.
> http://www.micrel.com/_PDF/Ethernet/datasheets/ksz9021rl-rn_ds.pdf
>
> Micrel ksz9031rnx Data Sheet, Revision 2.1. Dated 11/20/2014.
> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf
>
> Signed-off-by: Dinh Nguyen 

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

Re: [U-Boot] [PATCH 2/2] net: phy: micrel: fix divisor value for KSZ9031 phy skew

[Joe Hershberger]

On Wed, Jan 27, 2016 at 3:46 PM,   wrote:
> From: Dinh Nguyen 
>
> The picoseconds to register value divisor(ps_to_regval) should be 60 and not
> 200. Linux has KSZ9031_PS_TO_REG defined to be 60 as well. 60 is the correct
> divisor because the 4-bit skew values are defined from 0x(-420ps) to
> 0x(480ps), increments of 60.
>
> For example, a DTS skew value of 420, represents 0ps delay, which should be 
> 0x7.
> With the previous divisor of 200, it would result in 0x2, which represents a
> -300ps delay.
>
> With this patch, ethernet on the SoCFPGA DE0 Atlas is now able to work with
> 1Gb ethernet.
>
> References:
> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf -> page 26
>
> Signed-off-by: Dinh Nguyen 

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

Re: [U-Boot] [PATCH 2/2] net: phy: micrel: fix divisor value for KSZ9031 phy skew

[Joe Hershberger]

Hi Marek,

On Wed, Jan 27, 2016 at 4:07 PM, Marek Vasut  wrote:
> On Wednesday, January 27, 2016 at 10:46:00 PM, dingu...@opensource.altera.com
> wrote:
>> From: Dinh Nguyen 
>>
>> The picoseconds to register value divisor(ps_to_regval) should be 60 and
>> not 200. Linux has KSZ9031_PS_TO_REG defined to be 60 as well. 60 is the
>> correct divisor because the 4-bit skew values are defined from
>> 0x(-420ps) to 0x(480ps), increments of 60.
>>
>> For example, a DTS skew value of 420, represents 0ps delay, which should be
>> 0x7. With the previous divisor of 200, it would result in 0x2, which
>> represents a -300ps delay.
>>
>> With this patch, ethernet on the SoCFPGA DE0 Atlas is now able to work with
>> 1Gb ethernet.
>>
>> References:
>> http://www.micrel.com/_PDF/Ethernet/datasheets/KSZ9031RNX.pdf -> page 26
>>
>> Signed-off-by: Dinh Nguyen 
>
> This is fine, thanks for spotting it.
>
> Acked-by: Marek Vasut 
>
> Joe, will you pick these two and push for 2016.03 or shall I pick them ?

I'll get them.

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

Re: [U-Boot] [PATCH 1/2] hush: Pull out U-Boot prompt display and read functionality

[Simon Glass]

On 26 January 2016 at 20:47, Marek Vasut  wrote:
> Pull the code which displays U-Boot prompt and reads the command line
> into a separate function. No functional change.
>
> Signed-off-by: Marek Vasut 
> ---
>  common/cli_hush.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)

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

Re: [U-Boot] [PATCH v3 1/6] dm: implement a DMA uclass

[Simon Glass]

Hi Mugunthan,

On 27 January 2016 at 04:57, Mugunthan V N  wrote:
> Implement a DMA uclass so that the devices like ethernet, spi,
> mmc etc can offload the data transfers from/to the device and
> memory.
>
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/dma/Kconfig  | 15 +
>  drivers/dma/Makefile |  2 ++
>  drivers/dma/dma-uclass.c | 72 
>  include/dm/uclass-id.h   |  1 +
>  include/dma.h| 86 
> 
>  5 files changed, 176 insertions(+)
>  create mode 100644 drivers/dma/dma-uclass.c
>  create mode 100644 include/dma.h

Are you missing a change list on this patch?

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

Re: [U-Boot] [PATCH] serial: serial_stm32: move clock config from driver to board

[Simon Glass]

On 26 January 2016 at 19:12, Vikas Manocha  wrote:
> This patch removes the uart clock enable from serial driver & move it in the
> board code.
>
> Signed-off-by: Vikas Manocha 
> ---
>  arch/arm/include/asm/arch-stm32f4/stm32_defs.h | 15 
>  arch/arm/include/asm/arch-stm32f4/stm32_periph.h   | 27 +++
>  arch/arm/mach-stm32/stm32f4/clock.c| 20 +++
>  board/st/stm32f429-discovery/stm32f429-discovery.c |  3 ++
>  drivers/serial/serial_stm32.c  | 40 
> --
>  5 files changed, 65 insertions(+), 40 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_defs.h
>  create mode 100644 arch/arm/include/asm/arch-stm32f4/stm32_periph.h

Reviewed-by: Simon Glass 

You might consider adding a clock driver.

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

Re: [U-Boot] [PATCH] x86: Correct spi node alias

[Bin Meng]

On Thu, Jan 28, 2016 at 6:53 AM, Simon Glass  wrote:
> On 27 January 2016 at 01:56, Bin Meng  wrote:
>> With recent changes spi node was moved to a place as a subnode under
>> pch, so update the alias to refer to its correct place as well.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/dts/bayleybay.dts  | 4 ++--
>>  arch/x86/dts/broadwell_som-6896.dts | 4 ++--
>>  arch/x86/dts/chromebook_link.dts| 4 ++--
>>  arch/x86/dts/chromebox_panther.dts  | 4 ++--
>>  arch/x86/dts/crownbay.dts   | 4 ++--
>>  arch/x86/dts/galileo.dts| 4 ++--
>>  arch/x86/dts/minnowmax.dts  | 4 ++--
>>  7 files changed, 14 insertions(+), 14 deletions(-)
>
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] patman dies cryptially when a (valid) e-mail address contains parentheses (or is UTF-8)

[Albert ARIBAUD]

Hello Simon,

On Wed, 27 Jan 2016 15:53:45 -0700, Simon Glass 
wrote:
> Hi Albert,
> 
> On 27 January 2016 at 01:22, Albert ARIBAUD  wrote:
> > Hello Simon,
> >
> > I just noticed this while adding a Series-cc to my work address which
> > has parentheses: running patman (without -n) will result in
> >
> > sh: 1: Syntax error: "(" unexpected
> >
> > Which initially left me wondering what was happening until I realized
> > one of the Series-cc addresses had parentheses, e.g.
> >
> > Series-cc: "Name NAME (NAME)" 
> >
> > Note that the parentheses were in the free-form part of the address,
> > itself within double quotation marks, which appears valid wrt the RFC.
> >
> > I've tried using single quotes as a workaround:
> >
> > Series-cc: 'Name NAME (NAME)' 
> >
> > It kind-of-works in that patman does not die, but the resulting address
> > in the mail has outer double quotes and inner single quotes, e.g.
> >
> > "'Name NAME (NAME)'" 
> >
> > Aditionally, addresses with names in UTF-8 also fail, though
> > differently but still with a message somewhat unrelated to the actual
> > cause (UTF-8-name is the placeholder for a name containing UTF-8
> > diacritics):
> >
> > fatal: ambiguous argument 'UTF-8-name ':
> > unknown revision or path not in the working tree.
> > Use '--' to separate paths from revisions, like this:
> > 'git  [...] -- [...]'
> >
> > The same single-quote hack works it around, with the resulting
> > mail Cc:ing the name surrounded by single quotes only:
> >
> > Cc: 'UTF-8-name' 
> >
> > Cc:ing Marek who is a die-hard fan of UTF-8 names in e-mail
> > addresses. :)
> 
> I wonder if this is a problem with the cc_cmd code in patman.py?
> 
> # Called from git with a patch filename as argument
> # Printout a list of additional CC recipients for this patch
> elif options.cc_cmd:
> 
> Perhaps it should quote its output somehow?

I'll try and test that this week-end.

> Regards,
> Simon

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

Re: [U-Boot] [PATCH] board: ls2085aqds: Update kernel_size env variable

[Prabhakar Kushwaha]

> -Original Message-
> From: york sun
> Sent: Wednesday, January 27, 2016 11:09 PM
> To: Prabhakar Kushwaha ; u-
> b...@lists.denx.de
> Cc: Scott Wood 
> Subject: Re: [PATCH] board: ls2085aqds: Update kernel_size env variable
> 
> On 01/14/2016 08:53 PM, Prabhakar Kushwaha wrote:
> >
> >> -Original Message-
> >> From: york sun [mailto:york@nxp.com]
> >> Sent: Thursday, January 14, 2016 11:37 PM
> >> To: Prabhakar Kushwaha ;
> >> u-boot@lists.denx.de
> >> Cc: Scott Wood 
> >> Subject: Re: [PATCH] board: ls2085aqds: Update kernel_size env
> >> variable
> >>
> >> On 01/05/2016 09:00 PM, Prabhakar Kushwaha wrote:
> >>> kernel_size env variable is defined as 0x2800, it is beyond NOR
> >>> flash.
> >>>
> >>> Update kernel_size with 40MB kernel size.
> >>>
> >>> Signed-off-by: Prabhakar Kushwaha 
> >>> ---
> >>>  include/configs/ls2080aqds.h | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/include/configs/ls2080aqds.h
> >>> b/include/configs/ls2080aqds.h index ba84248..a402c06 100644
> >>> --- a/include/configs/ls2080aqds.h
> >>> +++ b/include/configs/ls2080aqds.h
> >>> @@ -346,7 +346,7 @@ unsigned long get_board_ddr_clk(void);
> >>>   "initrd_high=0x\0"  \
> >>>   "kernel_start=0x58110\0"\
> >>>   "kernel_load=0xa000\0"  \
> >>> - "kernel_size=0x2800\0"
> >>> + "kernel_size=0x280\0"
> >>>
> >>>  #ifdef CONFIG_FSL_MC_ENET
> >>>  #define CONFIG_FSL_MEMAC
> >>>
> >> Prabhakar,
> >>
> >> I am tired of these changes. Can you go over all the default settings
> >> and verify they all make sense?
> >
> > I agree.
> >
> > Let me review all settings and provide one patch to fix all of them at once.
> > Do you want to hold this patch till I check and provide patch (if
> > required)
> >
> >> A short while ago Scott found fdt_high was not  correct.
> >
> > Is this change part of code or not?
> >
> 
> Prabhakar,
> 
> Do you have update on this patch?
> 

I compared both QDS and RDB configuration files. They will be equal after 
merger of this patch. 

No patch update is required. 

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

Re: [U-Boot] [PATCH 0/7] fdt: Replace u-boot-dtb.bin with u-boot.bin

[Simon Glass]

Hi Hans,

On 25 January 2016 at 13:30, Simon Glass  wrote:
>
> At present u-boot.bin holds the plain U-Boot binary without the device tree.
> This is somewhat annoying since you need either u-boot.bin or u-boot-dtb.bin
> depending on whether device tree is used.
>
> This series adjusts the build such that u-boot.bin includes a device tree,
> and the plain binary is in u-boot-nodtb.bin. For now u-boot-dtb.bin remains
> the same.
>
> This should be acceptable since:
>
> - without OF_CONTROL, u-boot.bin still does not include a device tree
> - with OF_CONTROL, u-boot-dtb.bin does not change
>
> The main impact is build systems which are set up to use u-boot.bin as
> the output file and then add a device tree. These will have to change to use
> u-boot-nodtb.bin instead.
>
> The original decision to use a separate u-boot-dtb.bin was aimed at allowing
> any device tree file to be concatenated to the u-boot.bin image after the
> build. However this no-longer seems so important. More important is the
> convenience of using the same output file regardless of the setting for
> OF_CONTROL.

Do you have any comments on this series please?

>
>
> Simon Glass (7):
>   tegra: Drop generation of -nodtb file with OF_CONTROL
>   fdt: Build a U-Boot binary without device tree
>   fdt: Build an SPL binary without device tree
>   tegra: Always build a boot image with the same filename
>   socfpga: Simplify Makefile filenames
>   Makefile: Make u-boot.img the same as u-boot-dtb.img
>   Makefile: Drop unnecessary -dtb suffixes
>
>  Makefile | 67 
> ++--
>  scripts/Makefile.spl | 26 +---
>  2 files changed, 50 insertions(+), 43 deletions(-)
>
> --
> 2.7.0.rc3.207.g0ac5344
>

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Joe,

Am 27.01.2016 um 22:08 schrieb Joe Hershberger:

Hi Tom,

I'm playing with the idea of including the patchwork patch ID in the
commit message of each commit that I apply to provide better
cross-reference ability.

* Access to comments on patches
* Clarity on exactly which version of a patch was applied
* No need to search by patch subject

Here is an example in a working branch:

http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a

What do you (or anyone else) think?


Good idea, I would prefer:

X-Patchwork-Id: 561384

Thats what is in the mbox file, you download from patchwork ...

bye,
Heiko
--
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] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Tom,

Am 28.01.2016 um 00:45 schrieb Tom Rini:

On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:

On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:

On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:

Hi Tom,

I'm playing with the idea of including the patchwork patch ID in the
commit message of each commit that I apply to provide better
cross-reference ability.

* Access to comments on patches
* Clarity on exactly which version of a patch was applied
* No need to search by patch subject

Here is an example in a working branch:

http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a


I'd prfer Patchwork or Patchwork-ID or something not just Patch.


Would it be more or less compelling if it had a format similar this?

Patchwork: https://patchwork.ozlabs.org/patch/571773/


Yes.


Sorry, for dummy question ... what should I see in the above link?




What do you (or anyone else) think?


Well, I'm not a super fan of it.  For your second point, this is why I
use bundles, mutt and a macro.  For the other points, at least I find
google does a good job pulling up the right patch at least.


Bundles seem awkward. Perhaps I'm just not using them effectively.
What benefit do they give you? How are they part of your workflow?


OK, I'm going to delete this in a few days but here's my bundle for the
last import I did:
https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
My flow is:
1) Assign all unassigned patches
2) Open my todo list in patchwork
3) Create a bundle with all of the patches I want based on my critera at
the time.
4) Download bundle as mbox, git am -3 it, get big build going.
5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
at first
6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
each email group reply, run macro to insert applied message, postponed
7) Check output from big build, assuming good results, push and spam out
all of my queued messages.


Out of topic  maybe tbot can help you here a lot. I have an automated
build for example for the smartweb board [1], which does:

+  - clone u-boot.git
+  - set toolchain
+  - get a list of patchwork patches from my U-Boots ToDo list
+  - download all of them, and check them with checkpatch
+and apply them to u-boot.git
+  - compile U-Boot for the smartweb board
+  - install the resulting images on the smartweb board
+  - boot U-boot
+  - test DFU
+  - more TC should be added here for testing U-Boot

added to this list in the meantime some ported DUTS tests now,
last build see:
http://xeidos.ddns.net/buildbot/builders/smartweb_dfu/builds/48/steps/shell/logs/tbotlog
(currently I have 3 boards doing such tests periodically)

So, if you have a well-kept ToDo list in patchwork, this testcase
does a lot automatically (incl. execute testcases on board(s)) ...
You have only to look in the morning on for example a webpage
if all tests are "green" [2] ...

Then you can be sure, all patches in your ToDo list are checkpatch
clena, apply without errors to current master, compile clean and do not
break the boards you test u-boot ... (at last the testcases you run on
it).

Ok, I did not tried it with bundles, but it should also be possible to
download all patches you have in a bundle ... simple add a testcase
for downloading patches in a bundle only ...

Also an idea could be, to send an automated EMail if checkpatch
drops warnings/errors or if "git am" fails" ... but I do not really
know, if this would be a good idea ...

Also with the idea of tbot, you do not really need the hw at the place
where tbot runs ... for my example I run tbot on a raspberry pi in
Letkes/hungary, the boards are in munich/germany. So it is possible,
to test on boards, which other people have somewhere and give you
access to them ...

bye,
Heiko
[1] http://lists.denx.de/pipermail/u-boot/2016-January/243248.html
search there for:
"automated Testsetup with buildbot and tbot doing cyclic tests"

[2] http://xeidos.ddns.net/buildbot/tgrid
--
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] siemens,at91: enable features for smartweb

[Heiko Schocher]

Hello Samuel,

Am 27.01.2016 um 15:56 schrieb Samuel Egli:

From: Matthias Michel 

New features for smartweb:
* switch to hush command parser
* change autoboot stop to 
* allow to write ethaddr

Signed-off-by: Matthias Michel 
Reviewed-by: Samuel Egli 
Cc: Roger Meier 
Cc: Heiko Schocher 
---
  configs/smartweb_defconfig |  5 -
  include/configs/smartweb.h | 14 ++
  2 files changed, 14 insertions(+), 5 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko


diff --git a/configs/smartweb_defconfig b/configs/smartweb_defconfig
index ee4340f..654bb4b 100644
--- a/configs/smartweb_defconfig
+++ b/configs/smartweb_defconfig
@@ -3,4 +3,7 @@ CONFIG_ARCH_AT91=y
  CONFIG_TARGET_SMARTWEB=y
  CONFIG_SPL=y
  CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9260"
-CONFIG_SYS_PROMPT="U-Boot> "
+CONFIG_SYS_PROMPT="U-Boot# "
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Autobooting in %d seconds, press \"\" to 
stop\n"
+CONFIG_AUTOBOOT_STOP_STR="\x1b\x1b"
diff --git a/include/configs/smartweb.h b/include/configs/smartweb.h
index 44d1d5a..de7b6bc 100644
--- a/include/configs/smartweb.h
+++ b/include/configs/smartweb.h
@@ -49,10 +49,18 @@
  #define CONFIG_BOARD_EARLY_INIT_F /* call board_early_init_f() */
  #define CONFIG_DISPLAY_CPUINFO/* display CPU Info at startup 
*/

+/* We set the max number of command args high to avoid HUSH bugs. */
+#define CONFIG_SYS_MAXARGS32
+
  /* setting board specific options */
-# define CONFIG_MACH_TYPE  MACH_TYPE_SMARTWEB
-#define CONFIG_CMDLINE_EDITING
+#define CONFIG_MACH_TYPE   MACH_TYPE_SMARTWEB
+#define CONFIG_AUTO_COMPLETE
+#define CONFIG_ENV_OVERWRITE1 /* Overwrite ethaddr / serial# */
+#define CONFIG_SYS_HUSH_PARSER/* use "hush" command parser */
+#define CONFIG_SYS_PROMPT_HUSH_PS2  "> "
  #define CONFIG_AUTO_COMPLETE
+#define CONFIG_SYS_AUTOLOAD "yes"
+#define CONFIG_RESET_TO_RETRY

  /* The LED PINs */
  #define CONFIG_RED_LEDAT91_PIN_PA9
@@ -184,9 +192,7 @@
  /* General Boot Parameter */
  #define CONFIG_BOOTDELAY  3
  #define CONFIG_BOOTCOMMAND"run flashboot"
-#define CONFIG_BOOT_RETRY_TIME  30
  #define CONFIG_SYS_CBSIZE 512
-#define CONFIG_SYS_MAXARGS 16
  #define CONFIG_SYS_PBSIZE \
(CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
  #define CONFIG_SYS_LONGHELP



--
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

[U-Boot] [PATCH] fastboot: update error and warning messages

[Steve Rae]

Fix the formatting in error messages, and demote one error message
to a warning, as it is only informational.

Signed-off-by: Steve Rae 
---

 drivers/usb/gadget/f_fastboot.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 87e54eb..a54b4ee 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -382,7 +382,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
 
strsep(, ":");
if (!cmd) {
-   error("missing variable\n");
+   error("missing variable");
fastboot_tx_write_str("FAILmissing var");
return;
}
@@ -413,7 +413,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request 
*req)
else
strcpy(response, "FAILValue not set");
} else {
-   error("unknown variable: %s\n", cmd);
+   printf("WARNING: unknown variable: %s\n", cmd);
strcpy(response, "FAILVariable not implemented");
}
fastboot_tx_write_str(response);
@@ -561,7 +561,7 @@ static void cb_flash(struct usb_ep *ep, struct usb_request 
*req)
 
strsep(, ":");
if (!cmd) {
-   error("missing partition name\n");
+   error("missing partition name");
fastboot_tx_write_str("FAILmissing partition name");
return;
}
@@ -683,7 +683,7 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
}
 
if (!func_cb) {
-   error("unknown command: %s\n", cmdbuf);
+   error("unknown command: %s", cmdbuf);
fastboot_tx_write_str("FAILunknown command");
} else {
if (req->actual < req->length) {
@@ -691,7 +691,7 @@ static void rx_handler_command(struct usb_ep *ep, struct 
usb_request *req)
buf[req->actual] = 0;
func_cb(ep, req);
} else {
-   error("buffer overflow\n");
+   error("buffer overflow");
fastboot_tx_write_str("FAILbuffer overflow");
}
}
-- 
1.8.5

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Tom Rini]

On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:
> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
> >> Hi Tom,
> >>
> >> I'm playing with the idea of including the patchwork patch ID in the
> >> commit message of each commit that I apply to provide better
> >> cross-reference ability.
> >>
> >> * Access to comments on patches
> >> * Clarity on exactly which version of a patch was applied
> >> * No need to search by patch subject
> >>
> >> Here is an example in a working branch:
> >>
> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
> >
> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
> 
> Would it be more or less compelling if it had a format similar this?
> 
> Patchwork: https://patchwork.ozlabs.org/patch/571773/

Yes.

> >> What do you (or anyone else) think?
> >
> > Well, I'm not a super fan of it.  For your second point, this is why I
> > use bundles, mutt and a macro.  For the other points, at least I find
> > google does a good job pulling up the right patch at least.
> 
> Bundles seem awkward. Perhaps I'm just not using them effectively.
> What benefit do they give you? How are they part of your workflow?

OK, I'm going to delete this in a few days but here's my bundle for the
last import I did:
https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
My flow is:
1) Assign all unassigned patches
2) Open my todo list in patchwork
3) Create a bundle with all of the patches I want based on my critera at
the time.
4) Download bundle as mbox, git am -3 it, get big build going.
5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
at first
6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
each email group reply, run macro to insert applied message, postponed
7) Check output from big build, assuming good results, push and spam out
all of my queued messages.

-- 
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] Include patchwork patch ID in commit message?

[Bin Meng]

On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini  wrote:
> On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
>> On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini  wrote:
>> > On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
>> >> On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:
>> >> > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
>> >> >> Hi Tom,
>> >> >>
>> >> >> I'm playing with the idea of including the patchwork patch ID in the
>> >> >> commit message of each commit that I apply to provide better
>> >> >> cross-reference ability.
>> >> >>
>> >> >> * Access to comments on patches
>> >> >> * Clarity on exactly which version of a patch was applied
>> >> >> * No need to search by patch subject
>> >> >>
>> >> >> Here is an example in a working branch:
>> >> >>
>> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>> >> >
>> >> > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
>> >>
>> >> Would it be more or less compelling if it had a format similar this?
>> >>
>> >> Patchwork: https://patchwork.ozlabs.org/patch/571773/
>> >
>> > Yes.
>>
>> Are you being funny (more and less == not)? Or did you miss-read? :)
>
> Oops, yes, misread, yes, I like that.
>
>> >> >> What do you (or anyone else) think?
>> >> >
>> >> > Well, I'm not a super fan of it.  For your second point, this is why I
>> >> > use bundles, mutt and a macro.  For the other points, at least I find
>> >> > google does a good job pulling up the right patch at least.
>> >>
>> >> Bundles seem awkward. Perhaps I'm just not using them effectively.
>> >> What benefit do they give you? How are they part of your workflow?
>> >
>> > OK, I'm going to delete this in a few days but here's my bundle for the
>>
>> Doesn't that mean it will very soon not be traceable exactly which
>> patch version was applied? What I was proposing would mean that the
>> commit message could continue to refer back to the patch even if
>> archived.
>
> It means the the link I gave for the bundle will be gone.  The patches
> will be there, but I will also move them from Under Review to Accepted.
>
>> > last import I did:
>> > https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
>> > My flow is:
>> > 1) Assign all unassigned patches
>> > 2) Open my todo list in patchwork
>> > 3) Create a bundle with all of the patches I want based on my critera at
>> > the time.
>> > 4) Download bundle as mbox, git am -3 it, get big build going.
>> > 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
>> > at first
>> > 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
>> > each email group reply, run macro to insert applied message, postponed
>> > 7) Check output from big build, assuming good results, push and spam out
>> > all of my queued messages.
>>
>> Gotcha. Thanks!
>>
>> I'm trying to improve my workflow now, and this Patch tag was
>> something that came out of it. It's not required for the workflow, but
>> it is free to do within it. It has the potential to slightly simplify
>> one possible workflow, so no big deal.
>>
>> If people think it will be simply noise, I'll leave it out.
>>
>> I think this may speed up cross-referencing. Seemed like a good thing.
>
> My concern is that since it's not injected by patchwork already I would
> have to add it to each commit.  Today, unless I need to either make
> something apply or do a minor fixup to the contents, I don't modify any
> commit message, so my git am is it.

Does it make sense to enhance patchwork to inject such link into the
commit automatically? It can also be a project configuration option so
that other projects tracked by patchwork can turn it on on their
needs.

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

Re: [U-Boot] [PATCH 2/2] include:configs: Add usb device-tree fixup for all fsl platforms

[Ramneek Mehresh]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Wednesday, January 27, 2016 1:05 PM
> To: Ramneek Mehresh 
> Cc: Ramneek Mehresh ; u-
> b...@lists.denx.de; Simon Glass 
> Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup for all 
> fsl
> platforms
> 
> On Wednesday, January 27, 2016 at 05:30:51 AM, Ramneek Mehresh wrote:
> > > -Original Message-
> > > From: Marek Vasut [mailto:ma...@denx.de]
> > > Sent: Wednesday, January 27, 2016 9:57 AM
> > > To: Ramneek Mehresh 
> > > Cc: Ramneek Mehresh ; u-
> > > b...@lists.denx.de; Simon Glass 
> > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup
> > > for all fsl platforms
> > >
> > > On Wednesday, January 27, 2016 at 05:14:00 AM, Ramneek Mehresh
> wrote:
> > > > > -Original Message-
> > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > Sent: Tuesday, January 26, 2016 4:58 PM
> > > > > To: Ramneek Mehresh 
> > > > > Cc: u-boot@lists.denx.de
> > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > > fixup for all fsl platforms
> > > > >
> > > > > On Tuesday, January 26, 2016 at 12:36:58 PM, Ramneek Mehresh
> wrote:
> > > > > > Add usb device-tree fixup for all relevant fsl ppc and arm
> > > > > > platforms
> > > > > >
> > > > > > Signed-off-by: Ramneek Mehresh
> > >
> > > 
> > >
> > > > > > ---
> > > > > >
> > > > > >  board/freescale/b4860qds/b4860qds.c | 2 +-
> > > > > >  board/freescale/bsc9131rdb/bsc9131rdb.c | 2 ++
> > > > > >  board/freescale/bsc9132qds/bsc9132qds.c | 2 ++
> > > > > >  board/freescale/corenet_ds/corenet_ds.c | 4 
> > > > > >  board/freescale/ls2080aqds/ls2080aqds.c | 4 
> > > > > >  board/freescale/ls2080ardb/ls2080ardb.c | 4 
> > > > > >  board/freescale/mpc8308rdb/mpc8308rdb.c | 4 
> > > > > >  board/freescale/mpc8315erdb/mpc8315erdb.c   | 2 ++
> > > > > >  board/freescale/mpc837xemds/mpc837xemds.c   | 2 ++
> > > > > >  board/freescale/mpc837xerdb/mpc837xerdb.c   | 2 ++
> > > > > >  board/freescale/mpc8536ds/mpc8536ds.c   | 2 +-
> > > > > >  board/freescale/p1010rdb/p1010rdb.c | 2 +-
> > > > > >  board/freescale/p1022ds/p1022ds.c   | 2 +-
> > > > > >  board/freescale/p1023rdb/p1023rdb.c | 2 +-
> > > > > >  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +-
> > > > > >  board/freescale/p1_twr/p1_twr.c | 3 +++
> > > > > >  board/freescale/p2041rdb/p2041rdb.c | 2 +-
> > > > > >  board/freescale/t102xqds/t102xqds.c | 2 +-
> > > > > >  board/freescale/t102xrdb/t102xrdb.c | 3 +++
> > > > > >  board/freescale/t1040qds/t1040qds.c | 2 +-
> > > > > >  board/freescale/t104xrdb/t104xrdb.c | 2 +-
> > > > > >  board/freescale/t208xqds/t208xqds.c | 3 +++
> > > > > >  board/freescale/t208xrdb/t208xrdb.c | 3 +++
> > > > > >  board/freescale/t4qds/t4240emu.c| 3 +++
> > > > > >  board/freescale/t4qds/t4240qds.c| 3 +++
> > > > > >  board/freescale/t4rdb/t4240rdb.c| 3 +++
> > > > > >  include/configs/B4860QDS.h  | 1 +
> > > > > >  include/configs/BSC9131RDB.h| 1 +
> > > > > >  include/configs/BSC9132QDS.h| 3 ++-
> > > > > >  include/configs/MPC8308RDB.h| 3 +++
> > > > > >  include/configs/MPC8315ERDB.h   | 1 +
> > > > > >  include/configs/MPC837XEMDS.h   | 3 ++-
> > > > > >  include/configs/MPC837XERDB.h   | 1 +
> > > > > >  include/configs/MPC8536DS.h | 1 +
> > > > > >  include/configs/P1010RDB.h  | 1 +
> > > > > >  include/configs/P1022DS.h   | 1 +
> > > > > >  include/configs/P1023RDB.h  | 1 +
> > > > > >  include/configs/P2041RDB.h  | 1 +
> > > > > >  include/configs/T102xQDS.h  | 1 +
> > > > > >  include/configs/T102xRDB.h  | 1 +
> > > > > >  include/configs/T1040QDS.h  | 1 +
> > > > > >  include/configs/T104xRDB.h  | 1 +
> > > > > >  include/configs/T208xQDS.h  | 1 +
> > > > > >  include/configs/T208xRDB.h  | 1 +
> > > > > >  include/configs/T4240QDS.h  | 1 +
> > > > > >  include/configs/corenet_ds.h| 1 +
> > > > > >  include/configs/ls2080aqds.h| 1 +
> > > > > >  include/configs/ls2080ardb.h| 1 +
> > > > > >  include/configs/p1_p2_rdb_pc.h  | 1 +
> > > > > >  include/configs/p1_twr.h| 1 +
> > > > > >  50 files changed, 85 insertions(+), 12 deletions(-)
> > > > >
> > > > > Each such new macro must be documented. What is the point of
> > > > > this bulk rename anyway?
> > > >
> > > > Yes, 

[U-Boot] patman dies cryptially when a (valid) e-mail address contains parentheses (or is UTF-8)

[Albert ARIBAUD]

Hello Simon,

I just noticed this while adding a Series-cc to my work address which
has parentheses: running patman (without -n) will result in

sh: 1: Syntax error: "(" unexpected

Which initially left me wondering what was happening until I realized
one of the Series-cc addresses had parentheses, e.g.

Series-cc: "Name NAME (NAME)" 

Note that the parentheses were in the free-form part of the address,
itself within double quotation marks, which appears valid wrt the RFC.

I've tried using single quotes as a workaround:

Series-cc: 'Name NAME (NAME)' 

It kind-of-works in that patman does not die, but the resulting address
in the mail has outer double quotes and inner single quotes, e.g.

"'Name NAME (NAME)'" 

Aditionally, addresses with names in UTF-8 also fail, though
differently but still with a message somewhat unrelated to the actual
cause (UTF-8-name is the placeholder for a name containing UTF-8
diacritics):

fatal: ambiguous argument 'UTF-8-name ':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

The same single-quote hack works it around, with the resulting
mail Cc:ing the name surrounded by single quotes only:

Cc: 'UTF-8-name' 

Cc:ing Marek who is a die-hard fan of UTF-8 names in e-mail
addresses. :)

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

Re: [U-Boot] [PATCH 2/2] include:configs: Add usb device-tree fixup for all fsl platforms

[Marek Vasut]

On Wednesday, January 27, 2016 at 09:26:08 AM, Ramneek Mehresh wrote:
> > -Original Message-
> > From: Marek Vasut [mailto:ma...@denx.de]
> > Sent: Wednesday, January 27, 2016 1:05 PM
> > To: Ramneek Mehresh 
> > Cc: Ramneek Mehresh ; u-
> > b...@lists.denx.de; Simon Glass 
> > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup for
> > all fsl platforms
> > 
> > On Wednesday, January 27, 2016 at 05:30:51 AM, Ramneek Mehresh wrote:
> > > > -Original Message-
> > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > Sent: Wednesday, January 27, 2016 9:57 AM
> > > > To: Ramneek Mehresh 
> > > > Cc: Ramneek Mehresh ; u-
> > > > b...@lists.denx.de; Simon Glass 
> > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree fixup
> > > > for all fsl platforms
> > > > 
> > > > On Wednesday, January 27, 2016 at 05:14:00 AM, Ramneek Mehresh
> > 
> > wrote:
> > > > > > -Original Message-
> > > > > > From: Marek Vasut [mailto:ma...@denx.de]
> > > > > > Sent: Tuesday, January 26, 2016 4:58 PM
> > > > > > To: Ramneek Mehresh 
> > > > > > Cc: u-boot@lists.denx.de
> > > > > > Subject: Re: [PATCH 2/2] include:configs: Add usb device-tree
> > > > > > fixup for all fsl platforms
> > > > > > 
> > > > > > On Tuesday, January 26, 2016 at 12:36:58 PM, Ramneek Mehresh
> > 
> > wrote:
> > > > > > > Add usb device-tree fixup for all relevant fsl ppc and arm
> > > > > > > platforms
> > > > > > > 
> > > > > > > Signed-off-by: Ramneek Mehresh
> > > > 
> > > > 
> > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > >  board/freescale/b4860qds/b4860qds.c | 2 +-
> > > > > > >  board/freescale/bsc9131rdb/bsc9131rdb.c | 2 ++
> > > > > > >  board/freescale/bsc9132qds/bsc9132qds.c | 2 ++
> > > > > > >  board/freescale/corenet_ds/corenet_ds.c | 4 
> > > > > > >  board/freescale/ls2080aqds/ls2080aqds.c | 4 
> > > > > > >  board/freescale/ls2080ardb/ls2080ardb.c | 4 
> > > > > > >  board/freescale/mpc8308rdb/mpc8308rdb.c | 4 
> > > > > > >  board/freescale/mpc8315erdb/mpc8315erdb.c   | 2 ++
> > > > > > >  board/freescale/mpc837xemds/mpc837xemds.c   | 2 ++
> > > > > > >  board/freescale/mpc837xerdb/mpc837xerdb.c   | 2 ++
> > > > > > >  board/freescale/mpc8536ds/mpc8536ds.c   | 2 +-
> > > > > > >  board/freescale/p1010rdb/p1010rdb.c | 2 +-
> > > > > > >  board/freescale/p1022ds/p1022ds.c   | 2 +-
> > > > > > >  board/freescale/p1023rdb/p1023rdb.c | 2 +-
> > > > > > >  board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +-
> > > > > > >  board/freescale/p1_twr/p1_twr.c | 3 +++
> > > > > > >  board/freescale/p2041rdb/p2041rdb.c | 2 +-
> > > > > > >  board/freescale/t102xqds/t102xqds.c | 2 +-
> > > > > > >  board/freescale/t102xrdb/t102xrdb.c | 3 +++
> > > > > > >  board/freescale/t1040qds/t1040qds.c | 2 +-
> > > > > > >  board/freescale/t104xrdb/t104xrdb.c | 2 +-
> > > > > > >  board/freescale/t208xqds/t208xqds.c | 3 +++
> > > > > > >  board/freescale/t208xrdb/t208xrdb.c | 3 +++
> > > > > > >  board/freescale/t4qds/t4240emu.c| 3 +++
> > > > > > >  board/freescale/t4qds/t4240qds.c| 3 +++
> > > > > > >  board/freescale/t4rdb/t4240rdb.c| 3 +++
> > > > > > >  include/configs/B4860QDS.h  | 1 +
> > > > > > >  include/configs/BSC9131RDB.h| 1 +
> > > > > > >  include/configs/BSC9132QDS.h| 3 ++-
> > > > > > >  include/configs/MPC8308RDB.h| 3 +++
> > > > > > >  include/configs/MPC8315ERDB.h   | 1 +
> > > > > > >  include/configs/MPC837XEMDS.h   | 3 ++-
> > > > > > >  include/configs/MPC837XERDB.h   | 1 +
> > > > > > >  include/configs/MPC8536DS.h | 1 +
> > > > > > >  include/configs/P1010RDB.h  | 1 +
> > > > > > >  include/configs/P1022DS.h   | 1 +
> > > > > > >  include/configs/P1023RDB.h  | 1 +
> > > > > > >  include/configs/P2041RDB.h  | 1 +
> > > > > > >  include/configs/T102xQDS.h  | 1 +
> > > > > > >  include/configs/T102xRDB.h  | 1 +
> > > > > > >  include/configs/T1040QDS.h  | 1 +
> > > > > > >  include/configs/T104xRDB.h  | 1 +
> > > > > > >  include/configs/T208xQDS.h  | 1 +
> > > > > > >  include/configs/T208xRDB.h  | 1 +
> > > > > > >  include/configs/T4240QDS.h  | 1 +
> > > > > > >  include/configs/corenet_ds.h| 1 +
> > > > > > >  include/configs/ls2080aqds.h| 1 +
> > > > > > >  include/configs/ls2080ardb.h| 1 +
> > > > > > >  include/configs/p1_p2_rdb_pc.h  | 1 +
> > > > 

Re: [U-Boot] [PATCH v2 2/7] net: phy: genphy: Allow overwriting features

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> From: Sascha Hauer 
>
> of_set_phy_supported allows overwiting hardware capabilities of
> a phy with values from the devicetree. This does not work with
> the genphy driver though because the genphys config_init function
> will overwrite all values adjusted by of_set_phy_supported. Fix
> this by initialising the genphy features in the phy_driver struct
> and in config_init just limit the features to the ones the hardware
> can actually support. The resulting features are a subset of the
> devicetree specified features and the hardware features.
>
> This is a copy of the patch from Linux kernel, see
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c242a47238fa2a6a54af8a16e62b54e6e031d4bc
>
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Alexey Brodkin 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 7/7] net/designware: add support of max-speed device tree property

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> This property allows to specify fastest connection mode supported by
> the MAC (as opposed to features of the phy).
>
> There are situations when phy may handle faster modes than the
> MAC (or even it's particular implementation or even due to CPU being too
> slow).
>
> This property is a standard one in Linux kernel these days and some
> boards do already use it in their device tree descriptions.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Bin Meng 
> Cc: Joe Hershberger 
> Cc: Sonic Zhang 
> cc: Simon Glass 

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

Re: [U-Boot] [PATCH v2 2/2] net: phy: Add PHY driver for mv88e61xx switches

[Kevin Smith]

Hi Joe,

Thanks for the review.  ACK to all comments.  A few clarifications are 
included below.  I will submit a v3, including multichip addressing for 
Albert's platform.

On 01/26/2016 06:11 PM, Joe Hershberger wrote:
>> +   int reg, u16 data)
>> +{
>> +   struct mii_dev *phys_bus;
> Why "phys_bus"? Isn't it an mdio_bus? Maybe that would be a better name.
Agreed.  This is extracting the actual mdio bus from the "fake" indirect 
mii device (see below).  I will change to a better name.
>> +
>> +static int mv88e61xx_probe(struct phy_device *phydev)
>> +{
>> +   struct mii_dev *mii_dev;
>> +
>> +   /* This device requires indirect reads/writes to the PHY registers
>> +* which the generic PHY code can't handle.  Make a fake MII device 
>> to
>> +* handle reads/writes */
>> +   mii_dev = mdio_alloc();
>> +   if (!mii_dev)
>> +   return -1;
>>
>> +
>> +   /* Store the actual bus in the fake mii device */
>> +   mii_dev->priv = phydev->bus;
>> +   strncpy(mii_dev->name, "mv88e61xx_protocol", sizeof(mii_dev->name));
>> +   mii_dev->read = mv88e61xx_phy_read_bus;
>> +   mii_dev->write = mv88e61xx_phy_write_bus;
>> +
>> +   /* Replace the bus with the fake device */
> Fake how? This is a confusing comment to me as written.
The genphy functions assume that they can write to the PHY directly 
using the MII bus, and the address it uses is the address of a 
register.  This is not the case for this chip with multiple PHY 
interfaces, which have to be accessed indirectly.  To handle this, I 
have created a "fake" mii_dev whose read/write functions are the 
indirection functions, and stored the actual mdio_bus in the private 
data for the "fake" device, which is then used by the indirect 
functions.  This allows this driver to make use of common genphy stuff 
where appropriate.  Maybe "wrapper" or "indirect bus" is a better name 
for it.  Let me know if you have a preference or better idea.
>> +
>> +   mac_addr = phydev->addr;
>> +
>> +   for (i = 0; i < PORT_COUNT; i++) {
>> +   if ((1 << i) & CONFIG_MV88E61XX_PHY_PORTS) {
>> +   phydev->addr = i;
>> +   mv88e61xx_phy_enable(phydev, i);
>> +   mv88e61xx_phy_setup(phydev, i);
>> +   mv88e61xx_phy_config_port(phydev, i);
> These all return status, but are ignored.
Even if one fails, it seems appropriate to me to continue initializing 
the others and not bail completely.  Should I catch the error, print a 
warning and "continue" in the loop?  Or is completely bailing the right 
thing to do?  If there are some errors, but other successes, what should 
the function return?
>> +
>> +
>> +
>> +   /* After reset, the energy detect signal remains high for a few 
>> seconds
>> +* regardless of whether a cable is connected.  This function will
>> +* return false positives during this time. */
> This is OK?
Yes.  This is used to skip the autonegotiation process if nothing is 
plugged into the port.  If you have 5-6 ports enabled but only one cable 
plugged in, waiting for all the other autonegotiation timeouts takes a 
long time.  This tries to be smart and not wait when nothing is plugged 
in.  A false positive just tries to autonegotiate.  After the first 
autonegotiate timeout, the energy detection hysteresis (or whatever) has 
corrected itself, so you only have to wait for one.

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

Re: [U-Boot] [PATCH 00/17] arm: ls1021atwr: Convert to use driver model TSEC driver

[Joe Hershberger]

Hi Bin,

On Mon, Jan 25, 2016 at 8:45 PM, Bin Meng  wrote:
> On Wed, Jan 20, 2016 at 1:16 AM, york sun  wrote:
>> On 01/17/2016 09:16 PM, Bin Meng wrote:
>>> Joe, York,
>>>
>>> On Tue, Jan 12, 2016 at 2:41 PM, Bin Meng  wrote:
 This series adds driver model ethernet support to the Freescale
 TSEC ethernet driver and convert ls1021atwr board to use it.

 Enable the support in the ls1021atwr_nor_defconfig and
 ls1021atwr_nor_lpuart_defconfig configurations.


 Bin Meng (17):
   powerpc: bsc9132qds: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
   powerpc: c29xpcie: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
   powerpc: mpc8572ds: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
   powerpc: mpc8548cds: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
   powerpc: p1010rdb: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
   arm: ls1021atwr: Do not wrap pci_eth_init() with CONFIG_TSEC_ENET
>>
>> I think separating TSEC from PCI eth is correct.
>>
   net: tsec: fsl_mdio: Fix several cosmetic issues
   net: tsec: Move rx_idx and tx_idx to struct tsec_private
   net: tsec: Move rxbd and txbd to struct tsec_private
>>
>> I don't see problem with above change. I didn't test them though.
>>
>
> Thanks York.
>
   net: tsec: Adjust orders to avoid forward declaration of tsec_send()
   net: tsec: Use tsec_private pointer as the parameter for internal
 routines
   doc: dt-bindings: Describe Freescale TSEC ethernet controller
   net: tsec: Add driver model ethernet support
   net: tsec: Use priv->tbiaddr to initialize TBI PHY address
   arm: ls102xa: Rewrite the logic of ft_fixup_enet_phy_connect_type()
>
> Hi Joe, I see this series are assigned to you. If the first 15 patches
> are OK, please apply it directly so that I can save some time
> including them in v2.

OK, I have reviewed the first 15 and will take them now for build testing.

   arm: ls1021atwr: Disable CONFIG_E1000 temporarily
   arm: ls1021atwr: Convert to use driver model TSEC driver
>>
>
> Since York has some comments regarding to CONFIG_E1000, I will work on
> the remaining 2 patches in v2, together with DM PCI conversion.
>
>> I haven't tested your patch. Just a reminder, please keep it in mind to have
>> "git bisect" always working, in case we need to find something later. My
>> previous comment on disabling E1000 for ls1021atwr still stands.
>>
>> York
>>
>
> Regards,
> Bin
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] net: phy: introduce a quirk PHY_BROKEN_RESET

[Joe Hershberger]

On Tue, Jan 12, 2016 at 3:55 AM,   wrote:
> From: Shaohui Xie 
>
> Current driver always performs a phy soft reset when connecting the phy
> device, but soft reset is not always supported by a phy device, so
> introduce a quirk PHY_BROKEN_RESET to let such a phy device to skip soft
> reset. This commit uses 'flags' of phy device structure to store the
> quirk.
>
> Signed-off-by: Shaohui Xie 
> ---
>  drivers/net/phy/phy.c | 3 +++
>  include/phy.h | 1 +
>  2 files changed, 4 insertions(+)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 51b5746..2a36ae7 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -707,6 +707,9 @@ int phy_reset(struct phy_device *phydev)
> int timeout = 500;
> int devad = MDIO_DEVAD_NONE;
>
> +   if (phydev->flags == PHY_BROKEN_RESET)

Please mask off this bit so this test still work if someone adds a
different flag.

E.g.: if (phydev->flags & PHY_BROKEN_RESET)

> +   return 0;
> +
>  #ifdef CONFIG_PHYLIB_10G
> /* If it's 10G, we need to issue reset through one of the MMDs */
> if (is_10g_interface(phydev->interface)) {
> diff --git a/include/phy.h b/include/phy.h
> index 66cf61b..5f604a1 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -16,6 +16,7 @@
>  #include 
>
>  #define PHY_MAX_ADDR 32
> +#define PHY_BROKEN_RESET   (1 << 0) /* soft reset not supported */

Please name this something like PHY_FLAG_BROKEN_RESET.

>
>  #define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \
>  SUPPORTED_10baseT_Full | \
> --
> 2.1.0.27.g96db324
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] net: phy: implements probe for Cortina phy

[Joe Hershberger]

On Tue, Jan 12, 2016 at 3:55 AM,   wrote:
> From: Shaohui Xie 
>
> Cortine phy cannot support soft reset, this commit implements probe
> for Cortina PHY to tell phylib to skip phy soft reset by setting
> PHY_BROKEN_RESET in flags.
>
> Signed-off-by: Shaohui Xie 

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

Re: [U-Boot] [PATCH v3 2/5] ARM: at91: clock: add a new file to handle clock

[Andreas Bießmann]

Hi Wenyou,

On 10.12.2015 03:20, Wenyou Yang wrote:
> To reduce the duplicated code, add a new file to accommodate
> the peripheral's and system's clock handle code, shared with
> the SoCs with different ARM core.
> 
> Signed-off-by: Wenyou Yang 
> ---
> 
> Changes in v3:
>  - fix incorrectly used the indicator '&' to achieve the variable
>pointer of pmc->pcer and pmc->pcdr.
> 
> Changes in v2: None
> 
>  arch/arm/mach-at91/Makefile   |1 +
>  arch/arm/mach-at91/arm926ejs/clock.c  |7 
>  arch/arm/mach-at91/armv7/clock.c  |   26 
>  arch/arm/mach-at91/clock.c|   72 
> +
>  arch/arm/mach-at91/include/mach/clk.h |2 +
>  5 files changed, 75 insertions(+), 33 deletions(-)
>  create mode 100644 arch/arm/mach-at91/clock.c
> 
> diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
> index 5b89617..d071072 100644
> --- a/arch/arm/mach-at91/Makefile
> +++ b/arch/arm/mach-at91/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_SAMA5D4) += mpddrc.o spl_atmel.o matrix.o 
> atmel_sfr.o
>  obj-y += spl.o
>  endif
>  
> +obj-y += clock.o
>  obj-$(CONFIG_CPU_ARM920T)+= arm920t/
>  obj-$(CONFIG_CPU_ARM926EJS)  += arm926ejs/
>  obj-$(CONFIG_CPU_V7) += armv7/
> diff --git a/arch/arm/mach-at91/arm926ejs/clock.c 
> b/arch/arm/mach-at91/arm926ejs/clock.c
> index 8d6934e..c8b5e10 100644
> --- a/arch/arm/mach-at91/arm926ejs/clock.c
> +++ b/arch/arm/mach-at91/arm926ejs/clock.c
> @@ -242,10 +242,3 @@ void at91_mck_init(u32 mckr)
>   while (!(readl(>sr) & AT91_PMC_MCKRDY))
>   ;
>  }
> -
> -void at91_periph_clk_enable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> -
> - writel(1 << id, >pcer);
> -}
> diff --git a/arch/arm/mach-at91/armv7/clock.c 
> b/arch/arm/mach-at91/armv7/clock.c
> index 41dbf16..81e9f69 100644
> --- a/arch/arm/mach-at91/armv7/clock.c
> +++ b/arch/arm/mach-at91/armv7/clock.c
> @@ -150,32 +150,6 @@ void at91_mck_init(u32 mckr)
>   ;
>  }
>  
> -void at91_periph_clk_enable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> - u32 regval;
> -
> - if (id > AT91_PMC_PCR_PID_MASK)
> - return;
> -
> - regval = AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD_WRITE | id;
> -
> - writel(regval, >pcr);
> -}
> -
> -void at91_periph_clk_disable(int id)
> -{
> - struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> - u32 regval;
> -
> - if (id > AT91_PMC_PCR_PID_MASK)
> - return;
> -
> - regval = AT91_PMC_PCR_CMD_WRITE | id;
> -
> - writel(regval, >pcr);
> -}
> -
>  int at91_enable_periph_generated_clk(u32 id, u32 clk_source, u32 div)
>  {
>   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> new file mode 100644
> index 000..d1c4b76
> --- /dev/null
> +++ b/arch/arm/mach-at91/clock.c
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright (C) 2015 Atmel Corporation
> + * Wenyou Yang 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void at91_periph_clk_enable(int id)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> +#ifdef CPU_HAS_PCR
> + u32 regval;
> + u32 div_value;
> +
> + if (id > AT91_PMC_PCR_PID_MASK)
> + return;
> +
> + writel(id, >pcr);
> +
> + div_value = readl(>pcr) & AT91_PMC_PCR_DIV;
> +
> + regval = AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD_WRITE | id | div_value;
> +
> + writel(regval, >pcr);
> +#else
> + u32 mask = 0x01 << (id % 32);
> + void *addr = (id / 32)  ?  >pcer1 : >pcer;

Isn't the pmc->pcer1 only available on devices which have CPU_HAS_PCR?
The old behaviour would be to just access unconditionally the pmc->pcer
here. Could you please elaborate?

Andreas

> +
> + writel(mask, addr);
> +#endif
> +}
> +
> +void at91_periph_clk_disable(int id)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> +#ifdef CPU_HAS_PCR
> + u32 regval;
> +
> + if (id > AT91_PMC_PCR_PID_MASK)
> + return;
> +
> + regval = AT91_PMC_PCR_CMD_WRITE | id;
> +
> + writel(regval, >pcr);
> +#else
> + u32 mask = 0x01 << (id % 32);
> + void *addr = (id / 32)  ?  >pcdr1 : >pcdr;
> +
> + writel(mask, addr);
> +#endif
> +}
> +
> +void at91_system_clk_enable(int sys_clk)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(sys_clk, >scer);
> +}
> +
> +void at91_system_clk_disable(int sys_clk)
> +{
> + struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
> +
> + writel(sys_clk, >scdr);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/clk.h 
> b/arch/arm/mach-at91/include/mach/clk.h
> index ad83927..bef4e1c 100644
> --- a/arch/arm/mach-at91/include/mach/clk.h
> +++ b/arch/arm/mach-at91/include/mach/clk.h
> 

Re: [U-Boot] [PATCH] fsl/ddr: Add workaround for ERRATUM_A009942

[york sun]

On 01/05/2016 07:34 PM, Shengzhou Liu wrote:
> During the receive data training, the DDRC may complete on a
> non-optimal setting that could lead to data corruption or
> initialization failure.
> 
> Workaround: before setting MEM_EN, set DEBUG_29 register with
> specific value for different data rates.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  1 +
>  drivers/ddr/fsl/fsl_ddr_gen4.c| 18 ++
>  2 files changed, 19 insertions(+)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] arm: ls1021a: Adjust sata register default values

[york sun]

On 12/15/2015 09:58 PM, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian 
> 
> Updated the default sata register values to enhance the
> performance and stability.
> 
> Signed-off-by: Tang Yuantian 
> ---
>  arch/arm/cpu/armv7/ls102xa/ls102xa_sata.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 3/4] SECURE BOOT: separate function created for signature

[york sun]

On 12/08/2015 12:45 AM, Aneesh Bansal wrote:
> The code for image hash calculation, hash calculation from
> RSA signature and comparison of hashes has been mobed to a
> separate function.
> 
> Signed-off-by: Saksham Jain 
> Signed-off-by: Aneesh Bansal 
> ---
>  board/freescale/common/fsl_validate.c | 98 
> +++
>  1 file changed, 54 insertions(+), 44 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 15/17] arm: ls102xa: Rewrite the logic of ft_fixup_enet_phy_connect_type()

[Joe Hershberger]

On Tue, Jan 12, 2016 at 12:41 AM, Bin Meng  wrote:
> eth_get_dev_by_index() is an API which is not available in driver
> model. Use eth_get_dev_by_name() instead, which can also simplifly
> the code logic a little bit.
>
> Signed-off-by: Bin Meng 

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

Re: [U-Boot] [PATCH] ARM: zynq: Add function to get reboot status register value.

[Albert ARIBAUD]

Hello Moritz,

On Wed, 27 Jan 2016 14:53:30 +0100, Moritz Fischer
 wrote:
> Hi Michal,
> 
> On Wed, Jan 27, 2016 at 2:15 PM, Michal Simek  wrote:
> > On 27.1.2016 12:22, Moritz Fischer wrote:
> >> Signed-off-by: Moritz Fischer 
> >> ---
> >> Hi Michal,
> >>
> >>I was planning to use this in future to boot into recovery mode.
> >>The change is small enough I feel that we could directly take it.
> >>If you want to hold off until there's a user that's fine for me, too.
> >>
> >>Cheers,
> >>
> >>Moritz
> >> ---
> >>  arch/arm/mach-zynq/slcr.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
> >> index 05f4099..709711a 100644
> >> --- a/arch/arm/mach-zynq/slcr.c
> >> +++ b/arch/arm/mach-zynq/slcr.c
> >> @@ -166,6 +166,11 @@ u32 zynq_slcr_get_boot_mode(void)
> >>   return readl(_base->boot_mode);
> >>  }
> >>
> >> +u32 zynq_slcr_get_reboot_status(void)
> >> +{
> >> + return readl(_base->reboot_status);
> >> +}
> >> +
> >>  u32 zynq_slcr_get_idcode(void)
> >>  {
> >>   return (readl(_base->pss_idcode) & SLCR_IDCODE_MASK) >>
> >>
> >
> > Isn't this generating sparse warning if it is not used and declared?
> 
> Derp. It doesn't generate a warning for not being used, however for
> not being declared it does,
> the entry in sys_proto.h is missing:
> 
>   CHECK   arch/arm/mach-zynq/slcr.c
> arch/arm/mach-zynq/slcr.c:97:9: warning: cast to restricted __le32
> arch/arm/mach-zynq/slcr.c:97:9: warning: incorrect type in assignment
> (different base types)
> arch/arm/mach-zynq/slcr.c:97:9:expected unsigned int volatile
> [unsigned] 
> arch/arm/mach-zynq/slcr.c:97:9:got restricted __le32 [usertype] 
> arch/arm/mach-zynq/slcr.c:169:5: warning: symbol
> 'zynq_slcr_get_reboot_status' was not declared. Should it be static?
>   CC  arch/arm/mach-zynq/slcr.o
>   LD  arch/arm/mach-zynq/built-in.o
> 
> when added to header this becomes:
> 
>   CHECK   arch/arm/mach-zynq/slcr.c
> arch/arm/mach-zynq/slcr.c:97:9: warning: cast to restricted __le32
> arch/arm/mach-zynq/slcr.c:97:9: warning: incorrect type in assignment
> (different base types)
> arch/arm/mach-zynq/slcr.c:97:9:expected unsigned int volatile
> [unsigned] 
> arch/arm/mach-zynq/slcr.c:97:9:got restricted __le32 [usertype] 
>   CC  arch/arm/mach-zynq/slcr.o
>   LD  arch/arm/mach-zynq/built-in.o
> 
> These were there before ;-)
> 
> I can resend with the header line added,
> 
> Moritz

Please add the header line but I would prefer that you submit it
as part of the series where it is used. Changes small enough to be
taken directly can end up dead code just like bigger changes, only
harder to locate -- especially if the compiler does not complain about
them. :)

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

[U-Boot] [GIT PULL] Xilinx changes

[Michal Simek]

Hi Tom,

here is the branch with xilinx changes which are flying around.
It is targeting PowerPC, Microblaze, ARM and ARM64.
I can't see any build problem via buildman.

Thanks,
Michal


The following changes since commit 9e4de7fd4acc8f99b6d383c711d21c0159849629:

  Merge branch 'master' of http://git.denx.de/u-boot-sunxi (2016-01-26
17:45:37 -0500)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git master

for you to fetch changes up to f36919a8138ed7ecd3dbce4630e02936b13907da:

  ppc: xilinx-ppc440-generic: Wire LL_TEMAC driver (2016-01-27 15:57:20
+0100)


Michal Simek (75):
  microblaze: Remove CONSOLE_ARG
  microblaze: Move baudrate setting out driver selection
  serial: uartlite: Move driver to DM
  serial: uartlite: Add support for debug console
  serial: uartlite: Add uartlite to Kconfig
  microblaze: Enable uart16550 DM by default
  microblaze: Do not print eth device when DM_ETH is enabled
  microblaze: Enable PHYLIB via Kconfig
  microblaze: Remove unused I2C macros
  microblaze: Wire-up debug_uart in asm
  microblaze: Enable MICREL_KSZ9021
  net: axi_emac: Fix parentheses around operand !
  net: axi_emac: Show phy address instead of register content
  net: axi_emac: Pass directly pointer to register space
  net: axi_emac: Put iobase to private structure
  net: axi_emac: Pass private structure to phyread/phywrite
  net: axi_emac: Pass private structure where possible
  net: axi_emac: Move driver to DM
  net: axi_emac: Enable access to MDIO in probe
  net: axi_emac: Split recv from free_pkt
  net: axi_emac: Rename start, stop, write_hwaddr functions
  net: Add axi emac to Kconfig
  net: emaclite: Remove ancient OF probe function
  net: emaclite: Add MDIO support to driver
  net: emaclite: Convert MDIO to use register offset
  net: emaclite: Use indirect register access for tx_ping/pong
  net: emaclite: Use indirect register access for rx_ping/pong
  net: emaclite: Use indirect register access for TX reset
  net: emaclite: Fix logic around available TX buffers
  net: emaclite: Remove XEL_TSR_XMIT_ACTIVE_MASK flag
  net: emaclite: Use indirect reg access in send
  net: emaclite: Use indirect access in emaclite_recv
  net: emaclite: Move driver to DM
  net: emaclite: Rename start and stop functions
  net: emaclite: Let core to handle received packet
  net: emaclite: Move emaclite to Kconfig
  microblaze: Enable axi emac via Kconfig
  microblaze: Move eth configuration to Kconfig
  microblaze: Remove systemace from board file
  microblaze: Remove CONFIG_FIT from board file
  microblaze: Move CONFIG_NETCONSOLE to Kconfig
  microblaze: Remove empty file - cpu.c
  microblaze: Read information about RAM from DT
  microblaze: Enable HUSH via Kconfig
  microblaze: Fix board_init calling sequence
  fpga: Fix compilation warnings
  serial: zynq: Extend compatible string list
  serial: zynq: Fix address reading from DM
  net: phy: ti: Enable automatic crossover mode
  net: zynq: Change MDC setup for arm64
  ARM: zynq: Remove memory division by 2 for ECC case
  ARM: zynq: Do not select options if SPL is not enabled
  ARM: zynq: Enable SPI_FLASH for zc770 xm013 platform
  ARM: zynq: Move FLASH_BAR to Kconfig
  ARM: zynq: Clean DTSI coding style
  ARM: zynq: Fix all remaining zynq platform to use stdout-path
  ARM: zynq: Fix defconfig for zybo
  ARM: zynq: Move spi node to aligned location
  ARM64: zynqmp: Remove incorrect link to common config file
  ARM64: zynqmp: Use the same U-Boot version with/without ATF
  ARM64: zynqmp: Add initial support for the first silicon
  ARM64: zynqmp: Fix coding style in phy node
  ARM64: zynqmp: Add support for SD1 boot mode
  ARM64: zynqmp: Show information about bootmode
  ARM64: zynqmp: Differentiate EMMC boot mode
  ARM64: zynqmp: Fix bootmode SD_MODE1
  ARM64: zynqmp: Remove unneeded timer_init function
  ARM64: zynqmp: Enable advance memory test by default
  ARM64: zynqmp: Move memory setup to board file
  ARM64: zynqmp: Setup correct COUNTER_FREQUENCY for silicon
  ARM64: zynqmp: Allow overwrite identification string
  ARM64: zynqmp: Enable NATSEMI phys
  ARM64: zynqmp: Include GbE speed/duplex detection
  ARM64: zynqmp: Do not setup bootargs
  ARM: zynq: zynqmp: Line up checkboard message

Punnaiah Choudary Kalluri (1):
  ARM64: zynqmp: Correct the watchdog timer interrupt number

Ricardo Ribalda (22):
  ppc: xilinx-ppc440: Remove support for ml507
  ppc: xilinx-ppc405: Remove support for fx12mm
  xilinx-ppc440: Remove support for v5fx30teval
  .mailmap: Add all the mail alias for Ricardo Ribalda
  mailaddr: Update mail address
  ppc: 

Re: [U-Boot] [PATCH v2 5/7] include/net.h: add max_speed member in struct eth_pdata

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> This will be used for getting max speed mode of Ethernet interface that
> a particular MAC supports from Device Tree blob and later being used for
> phy configuration.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 4/7] drivers/net/phy: introduce phy_set_supported()

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> This new function will allow MAC drivers to override supported
> capabilities of the phy. It is required when MAC cannot handle all
> speeds supported by phy.
>
> For example phy supports up-to 1Gb connections while MAC may only work
> in modes up to 100 or even 10 Mbit/sec.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH] armv8: fsl-lsch3: fixup SYSCLK frequency in device tree

[york sun]

On 12/24/2015 03:55 AM, Prabhakar Kushwaha wrote:
> SYSCLK frequency is dependent on on-board switch settings. It may
> vary as per requirement. boot-loader is aware of board switch
> configurations.
> 
> So Fixup Linux device tree from boot-loader.
> 
> Signed-off-by: Prabhakar Kushwaha 
> CC: Mingkai Hu 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 3 +++
>  1 file changed, 3 insertions(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [Patch V2 3/3] armv8/ls1043aqds: enable qixis_reset command to boot from NAND/SD

[york sun]

On 12/31/2015 02:38 AM, Gong Qianyu wrote:
> From: Gong Qianyu 
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - No change.
> 
>  include/configs/ls1043aqds.h | 4 
>  1 file changed, 4 insertions(+)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH][v2] armv8: fsl-layerscape: fixes lsch2 serdes registers define

[york sun]

On 12/14/2015 02:13 AM, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> Fixes lsch2 SerDes registers define according to LS1043A RM Rev D.
> 
> Signed-off-by: Shaohui Xie 
> ---
> changes in v2:
> 1. fixes indent.
> 
>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  | 67 
> +++---
>  1 file changed, 47 insertions(+), 20 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] drivers/ddr/fsl: fsl_ddr_sdram_size remove unused controllers

[york sun]

On 01/14/2016 10:28 AM, Ed Swarthout wrote:
> Following commit 61bd2f75, exclude unused DDR controller from
> calculating RAM size for SPL boot.
> 
> Signed-off-by: Ed Swarthout 
> ---
> 
> Applies to v2016.01.
> Tested on ls2080aqds.
> 
>  drivers/ddr/fsl/main.c | 1 +
>  1 file changed, 1 insertion(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] armv8: ls2040a: Add support of LS2040A SoC

[york sun]

On 12/22/2015 03:18 AM, Pratiyush Srivastava wrote:
> Freescale's LS2040A is a another personality of LS2080A SoC
> without AIOP support consisting of 4 armv8 cores.
> 
> Signed-off-by: Pratiyush Mohan Srivastava 
> ---
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 1 +
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h | 1 +
>  2 files changed, 2 insertions(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH v2 1/7] net: phy: ensure Gigabit features are masked off if requested

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> From: Florian Fainelli 
>
> When a Gigabit PHY device is connected to a 10/100Mbits capable Ethernet
> MAC, the driver will restrict the phydev->supported modes to mask off
> Gigabit. If the Gigabit PHY comes out of reset with the Gigabit features
> set by default in MII_CTRL1000, it will keep advertising these feature,
> so by the time we call genphy_config_advert(), the condition on
> phydev->supported having the Gigabit features on is false, and we do not
> update MII_CTRL1000 with updated values, and we keep advertising Gigabit
> features, eventually configuring the PHY for Gigabit whilst the Ethernet
> MAC does not support that.
>
> This patches fixes the problem by ensuring that the Gigabit feature bits
> are always cleared in MII_CTRL1000, if the PHY happens to be a Gigabit
> PHY, and then, if Gigabit features are supported, setting those and
> updating MII_CTRL1000 accordingly.
>
> This is a copy of patch from Linux kernel, see
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5273e3a5ca94fbeb8e07d31203069220d5e682aa
>
> Signed-off-by: Florian Fainelli 
> Signed-off-by: Alexey Brodkin 
> Cc: Joe Hershberger 
> ---

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

Re: [U-Boot] [PATCH] armv8/ls1043aqds: Add support for >2GB memory

[york sun]

On 01/03/2016 07:12 PM, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> This patch also exposes the complete DDR region(s) to Linux.
> 
> Signed-off-by: Shaohui Xie 
> ---
>  board/freescale/ls1043aqds/ddr.c| 19 ---
>  board/freescale/ls1043aqds/ls1043aqds.c | 10 ++
>  include/configs/ls1043aqds.h|  2 +-
>  3 files changed, 27 insertions(+), 4 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 2/4] SECURE BOOT: separate functions for reading keys

[york sun]

On 12/08/2015 12:45 AM, Aneesh Bansal wrote:
> Separate functions are created for reading and checking the
> sanity of Public keys:
> - read_validate_single_key
> - read_validate_ie_tbl
> - read_validate_srk_table
> 
> Signed-off-by: Saksham Jain 
> Signed-off-by: Aneesh Bansal 
> ---
>  board/freescale/common/fsl_validate.c | 169 
> +++---
>  1 file changed, 96 insertions(+), 73 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 11/17] net: tsec: Use tsec_private pointer as the parameter for internal routines

[Joe Hershberger]

On Tue, Jan 12, 2016 at 12:41 AM, Bin Meng  wrote:
> For internal routines like redundant_init(), startup_tsec() and
> init_phy(), change to use tsec_private pointer as the parameter.
>
> Signed-off-by: Bin Meng 

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

Re: [U-Boot] [PATCH v2 3/7] net: phy: breakdown PHY_*_FEATURES defines

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> From: Florian Fainelli 
>
> Breakdown the PHY_*_FEATURES into per speed defines such that we can
> easily re-use them individually.
>
> Signed-off-by: Florian Fainelli 
> Signed-off-by: Alexey Brodkin 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH v2 6/7] net/designware: do explicit port selection for 1Gb mode

[Joe Hershberger]

On Wed, Jan 13, 2016 at 7:59 AM, Alexey Brodkin
 wrote:
> Current implementation only sets "port select" bit for non-1Gb mode.
> That works fine if GMAC has just exited reset state but we may as well
> change connection mode in runtime. Then we'll need to reprogram GMAC for
> that new mode of operation and if previous mode was 10 or 100 Mb and new
> one is 1 Gb we'll need to reset port mode bit.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Bin Meng 
> Cc: Joe Hershberger 
> Cc: Sonic Zhang 
> cc: Simon Glass 

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

Re: [U-Boot] [PATCH 1/5] mips: cache: Bulletproof the code against cornercases

[Marek Vasut]

On Wednesday, January 27, 2016 at 03:56:36 PM, Daniel Schwierzeck wrote:
> Am 27.01.2016 um 03:13 schrieb Marek Vasut:
> > This patch makes sure that the flush/invalidate_dcache_range() functions
> > can handle corner-case calls like this -- invalidate_dcache_range(0, 0,
> > 0); This call is valid and is happily produced by USB EHCI code for
> > example. The expected behavior of the cache function(s) in this case is
> > that they will do no operation, since the size is zero.
> > 
> > The current implementation though has a problem where such invocation
> > will result in a hard CPU hang. This is because under such conditions,
> > where the start_addr = 0 and stop = 0, the addr = 0 and aend =
> > 0xffe0 . The loop will then try to iterate over the entire address
> > space, which in itself is wrong. But iterating over the entire address
> > space might also hit some odd address which will cause bus hang. The
> > later happens on the Atheros MIPS.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Daniel Schwierzeck 
> > Cc: Hans de Goede 
> > ---
> > 
> >  arch/mips/lib/cache.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/mips/lib/cache.c b/arch/mips/lib/cache.c
> > index bf8ff59..7482005 100644
> > --- a/arch/mips/lib/cache.c
> > +++ b/arch/mips/lib/cache.c
> > @@ -95,6 +95,10 @@ void flush_dcache_range(ulong start_addr, ulong stop)
> > 
> > const void *addr = (const void *)(start_addr & ~(lsize - 1));
> > const void *aend = (const void *)((stop - 1) & ~(lsize - 1));
> > 
> > +   /* aend will be miscalculated when size is zero, so we return here */
> > +   if (start_addr == stop)
> > +   return;
> > +
> 
> you could additionally move the initialization of addr and aend behind
> this check like it's done in flush_cache()? That would save some CPU
> cycles.

The compiler would do the reordering anyway, it's not volatile so it's placement
would not save any cycles.

> > while (1) {
> > 
> > mips_cache(HIT_WRITEBACK_INV_D, addr);
> > if (addr == aend)
> > 
> > @@ -109,6 +113,10 @@ void invalidate_dcache_range(ulong start_addr, ulong
> > stop)
> > 
> > const void *addr = (const void *)(start_addr & ~(lsize - 1));
> > const void *aend = (const void *)((stop - 1) & ~(lsize - 1));
> > 
> > +   /* aend will be miscalculated when size is zero, so we return here */
> > +   if (start_addr == stop)
> > +   return;
> > +
> > 
> > while (1) {
> > 
> > mips_cache(HIT_INVALIDATE_D, addr);
> > if (addr == aend)

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

Re: [U-Boot] [PATCH 2/5] usb: ehci: Use map_physmem in ehci-generic

[Marek Vasut]

On Wednesday, January 27, 2016 at 03:21:17 PM, Alexey Brodkin wrote:
> Hi Marek,

Hi,

> On Wed, 2016-01-27 at 03:14 +0100, Marek Vasut wrote:
> > Some architectures, like MIPS, require remapping of the registers.
> > Add the map_physmem() call to handle it.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Daniel Schwierzeck 
> > Cc: Hans de Goede 
> > Cc: Masahiro Yamada 
> > Cc: Alexey Brodkin 
> > ---
> 
> Probably I'm missing something but I cannot apply it
> on top of current master:
> ->8--
> Applying: mips: cache: Bulletproof the code against cornercases
> Applying: usb: ehci: Use map_physmem in ehci-generic
> error: patch failed: drivers/usb/host/ehci-generic.c:5
> error: drivers/usb/host/ehci-generic.c: patch does not apply
> Patch failed at 0002 usb: ehci: Use map_physmem in ehci-generic
> The copy of the patch that failed is found in:
>/home/abrodkin/Projects/sources/git/u-boot/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort"
> ->8--
> 
> Note I'm applying entire series but not that only patch.

Probably because of 4feefdcfe916113ac6e1837ea22857f25fe1771c , that's
easy to fix though.

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

Re: [U-Boot] [Patch V2 2/3] armv8/ls1043aqds: fix qixis_reset command issue

[york sun]

On 12/31/2015 02:38 AM, Gong Qianyu wrote:
> From: Gong Qianyu 
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - No change.
> 
>  include/configs/ls1043aqds.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [Patch V2 1/3] freescale/qixis: Add support for booting from SD/QSPI

[york sun]

On 12/31/2015 02:37 AM, Gong Qianyu wrote:
> From: Gong Qianyu 
> 
> 1.Use "qixis_reset sd" to boot from SD
> 2.Use "qixis_reset sd_qspi" to boot from SD with QSPI support
> 3.Use "qixis_reset qspi" to boot from QSPI flash
> 
> On some SoCs such as LS1021A and LS1043A, IFC and QSPI could be
> pin-multiplexed. So the switches are different between SD boot with
> IFC support and SD boot with QSPI support. The default booting from
> SD is with IFC support.
> 
> Once QSPI is enabled(IFC disabled), only use I2C to access QIXIS.
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - Use qixis_write_i2c instead of QIXIS_WRITE once QSPI is enabled.
> 
>  board/freescale/common/qixis.c | 36 
>  1 file changed, 36 insertions(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] armv8: Enable all 8 DPMAC ports in LS2080A Personality

[york sun]

On 12/22/2015 03:17 AM, Pratiyush Srivastava wrote:
> LS2080A has support for 8 DPMAC ports out of which
> only 5 ports can be used at a time.
> Enabling all 8 DPMAC ports of LS2080A personality.
> 
> Signed-off-by: Pratiyush Mohan Srivastava 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c | 5 -
>  1 file changed, 5 deletions(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 14/17] net: tsec: Use priv->tbiaddr to initialize TBI PHY address

[Joe Hershberger]

On Tue, Jan 12, 2016 at 12:41 AM, Bin Meng  wrote:
> Add a new member 'tbiaddr' to tsec_private struct. For non-DM driver,
> it is initialized as CONFIG_SYS_TBIPA_VALUE, but for DM driver, we
> can get this from device tree. Update the bindings doc as well.
>
> Signed-off-by: Bin Meng 

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

Re: [U-Boot] [PATCH v3 3/5] ARM: cpu: at91: clean up peripheral clock code

[Andreas Bießmann]

Hi Wenyou,

On 10.12.2015 03:20, Wenyou Yang wrote:
> Due to introducing the new peripheral clock handle functions,
> use these functions to clean up the duplicated code.
> 
> Meanwhile, remove unneeded header file include, at91_pmc.h.
> 
> Signed-off-by: Wenyou Yang 

Reviewed-by: Andreas Bießmann 

There is a trivial fix required ...

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-at91/arm920t/at91rm9200_devices.c|   13 ++-
>  arch/arm/mach-at91/arm920t/timer.c |4 +-
>  arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c |   36 +-
>  arch/arm/mach-at91/arm926ejs/at91sam9261_devices.c |   28 --
>  arch/arm/mach-at91/arm926ejs/at91sam9263_devices.c |   37 +-
>  .../mach-at91/arm926ejs/at91sam9m10g45_devices.c   |   33 
>  arch/arm/mach-at91/arm926ejs/at91sam9n12_devices.c |   40 
> +---
>  arch/arm/mach-at91/arm926ejs/at91sam9rl_devices.c  |   28 --
>  arch/arm/mach-at91/arm926ejs/at91sam9x5_devices.c  |   38 +--
>  arch/arm/mach-at91/arm926ejs/cpu.c |1 -
>  arch/arm/mach-at91/arm926ejs/timer.c   |5 +--
>  arch/arm/mach-at91/armv7/cpu.c |1 -
>  arch/arm/mach-at91/armv7/timer.c   |1 -
>  arch/arm/mach-at91/phy.c   |1 -
>  arch/arm/mach-at91/sdram.c |1 -
>  15 files changed, 65 insertions(+), 202 deletions(-)
> 



> diff --git a/arch/arm/mach-at91/arm920t/timer.c 
> b/arch/arm/mach-at91/arm920t/timer.c
> index 6aa2994..3190961 100644
> --- a/arch/arm/mach-at91/arm920t/timer.c
> +++ b/arch/arm/mach-at91/arm920t/timer.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -31,8 +30,7 @@ int timer_init(void)
>   at91_tc_t *tc = (at91_tc_t *) ATMEL_BASE_TC;
>   at91_pmc_t *pmc = (at91_pmc_t *) ATMEL_BASE_PMC;

This line ^ has to be removed (undefined at91_pmc_t).

I'll do it whily applying

Andreas

>  
> - /* enables TC1.0 clock */
> - writel(1 << ATMEL_ID_TC0, >pcer);  /* enable clock */
> + at91_periph_clk_enable(ATMEL_ID_TC0);
>  
>   writel(0, >bcr);
>   writel(AT91_TC_BMR_TC0XC0S_NONE | AT91_TC_BMR_TC1XC1S_NONE |
> diff --git a/arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c 
> b/arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c
> index 5e0c0f5..912a966 100644
> --- a/arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c
> +++ b/arch/arm/mach-at91/arm926ejs/at91sam9260_devices.c
> @@ -11,8 +11,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  
>  /*
> @@ -32,51 +32,40 @@
>  
>  void at91_serial0_hw_init(void)
>  {
> - at91_pmc_t  *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
> -
>   at91_set_a_periph(AT91_PIO_PORTB, 4, 1);/* TXD0 */
>   at91_set_a_periph(AT91_PIO_PORTB, 5, PUP);  /* RXD0 */
> - writel(1 << ATMEL_ID_USART0, >pcer);
> + at91_periph_clk_enable(ATMEL_ID_USART0);
>  }
>  
>  void at91_serial1_hw_init(void)
>  {
> - at91_pmc_t  *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
> -
>   at91_set_a_periph(AT91_PIO_PORTB, 6, 1);/* TXD1 */
>   at91_set_a_periph(AT91_PIO_PORTB, 7, PUP);  /* RXD1 */
> - writel(1 << ATMEL_ID_USART1, >pcer);
> + at91_periph_clk_enable(ATMEL_ID_USART1);
>  }
>  
>  void at91_serial2_hw_init(void)
>  {
> - at91_pmc_t  *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
> -
>   at91_set_a_periph(AT91_PIO_PORTB, 8, 1);/* TXD2 */
>   at91_set_a_periph(AT91_PIO_PORTB, 9, PUP);  /* RXD2 */
> - writel(1 << ATMEL_ID_USART2, >pcer);
> + at91_periph_clk_enable(ATMEL_ID_USART2);
>  }
>  
>  void at91_seriald_hw_init(void)
>  {
> - at91_pmc_t  *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
> -
>   at91_set_a_periph(AT91_PIO_PORTB, 14, PUP); /* DRXD */
>   at91_set_a_periph(AT91_PIO_PORTB, 15, 1);   /* DTXD */
> - writel(1 << ATMEL_ID_SYS, >pcer);
> + at91_periph_clk_enable(ATMEL_ID_SYS);
>  }
>  
>  #if defined(CONFIG_HAS_DATAFLASH) || defined(CONFIG_ATMEL_SPI)
>  void at91_spi0_hw_init(unsigned long cs_mask)
>  {
> - at91_pmc_t  *pmc= (at91_pmc_t *) ATMEL_BASE_PMC;
> -
>   at91_set_a_periph(AT91_PIO_PORTA, 0, PUP);  /* SPI0_MISO */
>   at91_set_a_periph(AT91_PIO_PORTA, 1, PUP);  /* SPI0_MOSI */
>   at91_set_a_periph(AT91_PIO_PORTA, 2, PUP);  /* SPI0_SPCK */
>  
> - /* Enable clock */
> - writel(1 << ATMEL_ID_SPI0, >pcer);
> + at91_periph_clk_enable(ATMEL_ID_SPI0);
>  
>   if (cs_mask & (1 << 0)) {
>   at91_set_a_periph(AT91_PIO_PORTA, 3, 1);
> @@ -106,14 +95,11 @@ void at91_spi0_hw_init(unsigned long cs_mask)
>  
>  void at91_spi1_hw_init(unsigned long cs_mask)
>  {

Re: [U-Boot] [PATCH v3 1/5] ARM: at91: asm/at91_pmc.h: fix trival register offset

[Andreas Bießmann]

On 10.12.2015 03:20, Wenyou Yang wrote:
> Remove unnecessary #ifdef CPU_HAS_PCR.
> 
> Signed-off-by: Wenyou Yang 

Reviewed-by: Andreas Bießmann 

> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-at91/include/mach/at91_pmc.h |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/include/mach/at91_pmc.h 
> b/arch/arm/mach-at91/include/mach/at91_pmc.h
> index 3f50f77..eb40194 100644
> --- a/arch/arm/mach-at91/include/mach/at91_pmc.h
> +++ b/arch/arm/mach-at91/include/mach/at91_pmc.h
> @@ -51,19 +51,15 @@ typedef struct at91_pmc {
>   u32 imr;/* 0x6C Interrupt Mask Register */
>   u32 reserved4[4];
>   u32 pllicpr;/* 0x80 Change Pump Current Register (SAM9) */
> - u32 reserved5[21];
> + u32 reserved5[24];
>   u32 wpmr;   /* 0xE4 Write Protect Mode Register (CAP0) */
>   u32 wpsr;   /* 0xE8 Write Protect Status Register (CAP0) */
> -#ifdef CPU_HAS_PCR
> - u32 reserved6[8];
> + u32 reserved6[5];
>   u32 pcer1;  /* 0x100 Periperial Clock Enable Register 1 */
>   u32 pcdr1;  /* 0x104 Periperial Clock Disable Register 1 */
>   u32 pcsr1;  /* 0x108 Periperial Clock Status Register 1 */
>   u32 pcr;/* 0x10c Periperial Control Register */
>   u32 ocr;/* 0x110 Oscillator Calibration Register */
> -#else
> - u32 reserved8[5];
> -#endif
>  } at91_pmc_t;
>  
>  #endif   /* end not assembly */
> 

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

Re: [U-Boot] [PATCH v2 0/7] net: add support for phy speed limitation

[Alexey Brodkin]

Hi Joe,

On Tue, 2016-01-19 at 07:02 +, Alexey Brodkin wrote:
> Hi Joe,
> 
> On Wed, 2016-01-13 at 16:59 +0300, Alexey Brodkin wrote:
> > In some cases Ethernet PHY and network itself might support speeds
> > which are not supported by Ethernet controller (MAC).
> > 
> > To support that kind of situation it is required to force limit
> > PHY so it is not configured for unsupported mode or even if PHY 
> > autonegotiated too high speed it will be reconfigured for slower mode.
> > 
> > Note this series is v2 because v1 patches were sent separately not being
> > aranged in series. And now I'm putting all patches in one series
> > and marking it v2 even though no changes were done in patches itself.
> > 
> > Alexey Brodkin (4):
> >   drivers/net/phy: introduce phy_set_supported()
> >   include/net.h: add max_speed member in struct eth_pdata
> >   net/designware: do explicit port selection for 1Gb mode
> >   net/designware: add support of max-speed device tree property
> > 
> > Florian Fainelli (2):
> >   net: phy: ensure Gigabit features are masked off if requested
> >   net: phy: breakdown PHY_*_FEATURES defines
> > 
> > Sascha Hauer (1):
> >   net: phy: genphy: Allow overwriting features
> > 
> >  drivers/net/designware.c | 16 +-
> >  drivers/net/designware.h |  1 +
> >  drivers/net/phy/phy.c| 77 
> > ++--
> >  include/net.h|  2 ++
> >  include/phy.h| 23 ++-
> >  5 files changed, 89 insertions(+), 30 deletions(-)
> 
> Please treat this as a polite reminder to review
> that series sometime soon.

Thank you for reviewing that series.
I'm wondering who's going to pick it up?

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

Re: [U-Boot] [PATCH v2] driver/ddr/fsl: Add workaround for A009663

[york sun]

On 12/16/2015 12:53 AM, Shengzhou Liu wrote:
> Erratum A-009663 workaround requires to set DDR_INTERVAL[BSTOPRE] to 0
> before setting DDR_SDRAM_CFG[MEM_EN] and set DDR_INTERVAL[BSTOPRE]
> to the desired value after DDR initialization has completed.
> 
> When DDR controller is configured to operate in auto-precharge
> mode(DDR_INTERVAL[BSTOPRE]=0), this workaround is not needed.
> 
> Signed-off-by: Shengzhou Liu 
> ---
> v2: add more comments.
> 
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  3 +++
>  arch/arm/include/asm/arch-ls102xa/config.h|  1 +
>  arch/powerpc/cpu/mpc85xx/cmd_errata.c |  3 +++
>  arch/powerpc/include/asm/config_mpc85xx.h |  2 ++
>  drivers/ddr/fsl/fsl_ddr_gen4.c| 10 ++
>  include/fsl_ddr_sdram.h   |  1 +
>  6 files changed, 20 insertions(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 4/4] SECURE BOOT: support for validation of dynamic image

[york sun]

On 12/08/2015 12:45 AM, Aneesh Bansal wrote:
> Some images to be validated are relocated to a dynamic
> address at run time. So, these addresses cannot be known
> befor hand while signing the images and creating the header
> offline.
> So, support is required to pass the image address to the
> validate function as an argument.
> If an address is provided to the function, the address
> field in Header is not read and is treated as a reserved
> field.
> 
> Signed-off-by: Saksham Jain 
> Signed-off-by: Aneesh Bansal 
> ---
>  board/freescale/common/cmd_esbc_validate.c | 10 ++---
>  board/freescale/common/fsl_validate.c  | 33 
> ++
>  include/fsl_validate.h |  7 +--
>  3 files changed, 32 insertions(+), 18 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH 1/4] SECURE BOOT: change prototype of fsl_secboot_validate function

[york sun]

On 12/08/2015 12:45 AM, Aneesh Bansal wrote:
> The prototype and defination of function fsl_secboot_validate
> has been changed to support calling this function from another
> function within u-boot.
> Only two aruments needed:
> 1) header address - Mandatory
> 2) SHA256 string - optional
> 
> Signed-off-by: Saksham Jain 
> Signed-off-by: Aneesh Bansal 
> ---
>  board/freescale/common/cmd_esbc_validate.c | 17 -
>  board/freescale/common/fsl_validate.c  | 18 +++---
>  include/fsl_validate.h |  5 ++---
>  3 files changed, 25 insertions(+), 15 deletions(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] armv8: ls2080a: Increase MC's DDR size to 512 MB

[york sun]

On 12/22/2015 03:19 AM, Pratiyush Srivastava wrote:
> Freescale's management complex (MC) uses System DDR for internal usage. 
> Increase used System DDR size from 256MB to 512 MB.
> 
> Signed-off-by: Pratiyush Mohan Srivastava 
> ---
>  include/configs/ls2080a_common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York


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

Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI

[Qianyu Gong]

Hi,

> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Thursday, January 28, 2016 3:30 PM
> To: Qianyu Gong 
> Cc: U-Boot Mailing List 
> Subject: Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with
> CONFIG_DM_PCI
> 
> On Thu, Jan 28, 2016 at 3:15 PM, Gong Qianyu  wrote:
> > From: Mingkai Hu 
> >
> > Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'.
> >
> > For legacy PCIe driver, it needs loop to read the vender_id from devie
> > 0 to devie 255 to check if there is device available.
> > Reading non-existen device will trigger the "Cannot read bus
> > configuration: -1" information.
> >
> > Signed-off-by: Mingkai Hu 
> > Signed-off-by: Gong Qianyu 
> > ---
> 
> Which pci controller are you testing?
> 
> [snip]
> 
> Regards,
> Bin

Designware PCIe controller on LS2085A.


Regards,
Qianyu

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

Re: [U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI

[Bin Meng]

On Thu, Jan 28, 2016 at 3:15 PM, Gong Qianyu  wrote:
> From: Mingkai Hu 
>
> Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'.
>
> For legacy PCIe driver, it needs loop to read the vender_id from
> devie 0 to devie 255 to check if there is device available.
> Reading non-existen device will trigger the "Cannot read bus
> configuration: -1" information.
>
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Gong Qianyu 
> ---

Which pci controller are you testing?

[snip]

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

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

[Bin Meng]

Hi Tom,

The following changes since commit b20c38a973a51bf3f663bd298c63ad1b8e0de445:

  arm: mvebu: Add support for the Armada XP theadorable board
(2016-01-27 07:45:43 +0100)

are available in the git repository at:

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

for you to fetch changes up to 81aaa3d9fce5ce9641e5f0c3354da876d859b3b6:

  x86: Correct spi node alias (2016-01-28 13:53:30 +0800)


Bin Meng (1):
  x86: Correct spi node alias

Miao Yan (4):
  x86: qemu: re-structure qemu_fwcfg_list_firmware()
  x86: qemu: setup PM IO base for ACPI in southbridge
  x86: qemu: add the ability to load and link ACPI tables from QEMU
  x86: config option for loading ACPI table from QEMU

Stefan Roese (4):
  x86: baytrail: Add documentation for FSP memory-down values
  x86: x86-common.h: Add generic FS commands
  misc: Add simple driver to enable the legacy UART on Winbond
Super IO chips
  x86: baytrail: Add option to disable the internal UART to
setup_early_uart()

 arch/x86/Kconfig |   9 +++
 arch/x86/cpu/baytrail/early_uart.c   |  10 ++-
 arch/x86/cpu/qemu/Kconfig|   7 ++
 arch/x86/cpu/qemu/Makefile   |   2 +
 arch/x86/cpu/qemu/fw_cfg.c   | 316
+
 arch/x86/cpu/qemu/qemu.c |  29 +
 arch/x86/dts/bayleybay.dts   |   4 +-
 arch/x86/dts/broadwell_som-6896.dts  |   4 +-
 arch/x86/dts/chromebook_link.dts |   4 +-
 arch/x86/dts/chromebox_panther.dts   |   4 +-
 arch/x86/dts/crownbay.dts|   4 +-
 arch/x86/dts/galileo.dts |   4 +-
 arch/x86/dts/minnowmax.dts   |   4 +-
 arch/x86/include/asm/arch-qemu/device.h  |   2 +
 arch/x86/include/asm/arch-qemu/qemu.h|   5 ++
 arch/x86/include/asm/fw_cfg.h|  70 +++-
 arch/x86/include/asm/u-boot-x86.h|   2 +-
 arch/x86/lib/Makefile|   2 +
 arch/x86/lib/acpi_table.c|   4 ++
 arch/x86/lib/fsp/fsp_support.c   |   2 +-
 doc/README.x86   |   2 +-
 doc/device-tree-bindings/misc/intel,baytrail-fsp.txt |  31 -
 drivers/misc/Kconfig |   8 +++
 drivers/misc/Makefile|   1 +
 drivers/misc/winbond_w83627.c|  41 
 include/configs/x86-common.h |   1 +
 include/winbond_w83627.h |  35 ++
 27 files changed, 569 insertions(+), 38 deletions(-)
 create mode 100644 drivers/misc/winbond_w83627.c
 create mode 100644 include/winbond_w83627.h

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

Re: [U-Boot] Include patchwork patch ID in commit message?

[Heiko Schocher]

Hello Bin,

Am 28.01.2016 um 02:49 schrieb Bin Meng:

On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini  wrote:

On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:

On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini  wrote:

On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:

On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini  wrote:

On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:

Hi Tom,

I'm playing with the idea of including the patchwork patch ID in the
commit message of each commit that I apply to provide better
cross-reference ability.

* Access to comments on patches
* Clarity on exactly which version of a patch was applied
* No need to search by patch subject

Here is an example in a working branch:

http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45846567deaebe27a334a


I'd prfer Patchwork or Patchwork-ID or something not just Patch.


Would it be more or less compelling if it had a format similar this?

Patchwork: https://patchwork.ozlabs.org/patch/571773/


Yes.


Are you being funny (more and less == not)? Or did you miss-read? :)


Oops, yes, misread, yes, I like that.


What do you (or anyone else) think?


Well, I'm not a super fan of it.  For your second point, this is why I
use bundles, mutt and a macro.  For the other points, at least I find
google does a good job pulling up the right patch at least.


Bundles seem awkward. Perhaps I'm just not using them effectively.
What benefit do they give you? How are they part of your workflow?


OK, I'm going to delete this in a few days but here's my bundle for the


Doesn't that mean it will very soon not be traceable exactly which
patch version was applied? What I was proposing would mean that the
commit message could continue to refer back to the patch even if
archived.


It means the the link I gave for the bundle will be gone.  The patches
will be there, but I will also move them from Under Review to Accepted.


last import I did:
https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/
My flow is:
1) Assign all unassigned patches
2) Open my todo list in patchwork
3) Create a bundle with all of the patches I want based on my critera at
the time.
4) Download bundle as mbox, git am -3 it, get big build going.
5) Open each patch link, check for Nak/Changed/Uncertanty that I missed
at first
6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for
each email group reply, run macro to insert applied message, postponed
7) Check output from big build, assuming good results, push and spam out
all of my queued messages.


Gotcha. Thanks!

I'm trying to improve my workflow now, and this Patch tag was
something that came out of it. It's not required for the workflow, but
it is free to do within it. It has the potential to slightly simplify
one possible workflow, so no big deal.

If people think it will be simply noise, I'll leave it out.

I think this may speed up cross-referencing. Seemed like a good thing.


My concern is that since it's not injected by patchwork already I would
have to add it to each commit.  Today, unless I need to either make
something apply or do a minor fixup to the contents, I don't modify any
commit message, so my git am is it.


Does it make sense to enhance patchwork to inject such link into the
commit automatically? It can also be a project configuration option so
that other projects tracked by patchwork can turn it on on their
needs.


+1

bye,
Heiko
--
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

[U-Boot] [PATCH 8/9] test/py: run sandbox in source directory

[Stephen Warren]

From: Stephen Warren 

Some unit tests expect the cwd of the sandbox process to be the root
of the source tree. Ensure that requirement is met.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_console_sandbox.py | 2 +-
 test/py/u_boot_spawn.py   | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/test/py/u_boot_console_sandbox.py 
b/test/py/u_boot_console_sandbox.py
index bbf41e788ba3..a7263f30b8ca 100644
--- a/test/py/u_boot_console_sandbox.py
+++ b/test/py/u_boot_console_sandbox.py
@@ -44,7 +44,7 @@ class ConsoleSandbox(ConsoleBase):
 '-d',
 self.config.build_dir + '/arch/sandbox/dts/test.dtb'
 ]
-return Spawn(cmd)
+return Spawn(cmd, cwd=self.config.source_dir)
 
 def kill(self, sig):
 """Send a specific Unix signal to the sandbox process.
diff --git a/test/py/u_boot_spawn.py b/test/py/u_boot_spawn.py
index 7451455671b9..0f52d3e945c7 100644
--- a/test/py/u_boot_spawn.py
+++ b/test/py/u_boot_spawn.py
@@ -20,11 +20,13 @@ class Spawn(object):
 sent to the process, and responses waited for.
 """
 
-def __init__(self, args):
+def __init__(self, args, cwd=None):
 """Spawn (fork/exec) the sub-process.
 
 Args:
-args: array of processs arguments. argv[0] is the command to 
execute.
+args: array of processs arguments. argv[0] is the command to
+  execute.
+cwd: the directory to run the process in, or None for no change.
 
 Returns:
 Nothing.
@@ -44,6 +46,8 @@ class Spawn(object):
 # run under "go" (www.go.cd). Perhaps this happens under any
 # background (non-interactive) system?
 signal.signal(signal.SIGHUP, signal.SIG_DFL)
+if cwd:
+os.chdir(cwd)
 os.execvp(args[0], args)
 except:
 print 'CHILD EXECEPTION:'
-- 
2.7.0

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

[U-Boot] [PATCH 9/9] test/py: run C-based unit tests

[Stephen Warren]

From: Stephen Warren 

Add tests that execute the existing C-based unit test commands. These
simply run the command and validate the overall result. For now,
fine-grained details are not mapped into separate pytest test results in
the current implementation. However, the detail is available in the log
file for inspection, if attention is needed.

Now that the DM unit test runs under test/py, remove the manual shell
script that invokes it.

Signed-off-by: Stephen Warren 
---
 test/dm/test-dm.sh   | 16 -
 test/py/tests/test_ut.py | 59 
 2 files changed, 59 insertions(+), 16 deletions(-)
 delete mode 100755 test/dm/test-dm.sh
 create mode 100644 test/py/tests/test_ut.py

diff --git a/test/dm/test-dm.sh b/test/dm/test-dm.sh
deleted file mode 100755
index 1a0f1509b415..
--- a/test/dm/test-dm.sh
+++ /dev/null
@@ -1,16 +0,0 @@
-#!/bin/sh
-
-die() {
-   echo $1
-   exit 1
-}
-
-NUM_CPUS=$(cat /proc/cpuinfo |grep -c processor)
-make O=sandbox sandbox_config || die "Cannot configure U-Boot"
-make O=sandbox -s -j${NUM_CPUS} || die "Cannot build U-Boot"
-dd if=/dev/zero of=spi.bin bs=1M count=2
-echo -n "this is a test" > testflash.bin
-dd if=/dev/zero bs=1M count=4 >>testflash.bin
-./sandbox/u-boot -d ./sandbox/arch/sandbox/dts/test.dtb -c "ut dm"
-rm spi.bin
-rm testflash.bin
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py
new file mode 100644
index ..b033ca54d756
--- /dev/null
+++ b/test/py/tests/test_ut.py
@@ -0,0 +1,59 @@
+# Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
+#
+# SPDX-License-Identifier: GPL-2.0
+
+import os.path
+import pytest
+
+@pytest.mark.buildconfigspec('ut_dm')
+def test_ut_dm(u_boot_console):
+"""Execute the "ut dm" command."""
+
+fn = u_boot_console.config.source_dir + '/testflash.bin'
+if not os.path.exists(fn):
+data = 'this is a test'
+data += '\x00' * ((4 * 1024 * 1024) - len(data))
+with open(fn, 'wb') as fh:
+fh.write(data)
+
+output = u_boot_console.run_command('ut dm')
+assert output.endswith('Failures: 0')
+
+@pytest.mark.buildconfigspec('ut_env')
+def test_ut_env(u_boot_console):
+"""Execute the "ut env" command."""
+
+output = u_boot_console.run_command('ut env')
+assert output.endswith('Failures: 0')
+
+@pytest.mark.buildconfigspec('ut_time')
+def test_ut_time(u_boot_console):
+"""Execute the "ut time" command."""
+
+output = u_boot_console.run_command('ut time')
+assert output.endswith('Test passed')
+
+@pytest.mark.buildconfigspec('sandbox')
+def test_ut_cmd(u_boot_console):
+"""Execute the "ut_cmd" command."""
+
+output = u_boot_console.run_command('ut_cmd')
+assert output.endswith('do_ut_cmd: Everything went swimmingly')
+
+@pytest.mark.buildconfigspec('sandbox')
+def test_ut_compression(u_boot_console):
+"""Execute the "ut_compression" command."""
+
+output = u_boot_console.run_command('ut_compression')
+assert output.endswith('ut_compression ok')
+
+# Even when this passes, it prints lots of scary messages such as:
+# Must RESET board to recover
+# Equally, it fails if "ut dm" has been run first in the U-Boot session.
+# Don't enable this test until those issues have been researched/solved.
+#@pytest.mark.buildconfigspec('sandbox')
+#def test_ut_compression(u_boot_console):
+#"""Execute the "ut_image_decomp" command."""
+#
+#output = u_boot_console.run_command('ut_image_decomp')
+#assert output.endswith('ut_image_decomp ok')
-- 
2.7.0

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

[U-Boot] [PATCH 6/9] test/py: correctly log xfail/xpass tests

[Stephen Warren]

From: Stephen Warren 

Tests can complete in passed, skipped, xpass, xfailed, or failed, states.
Currently the U-Boot log generation code doesn't handle the xfailed or
xpass states since they aren't used. Add support for the remaining states.
Without this, tests that xfail end up being reported as skipped.

Signed-off-by: Stephen Warren 
---
 test/py/conftest.py | 60 +
 test/py/multiplexed_log.css |  8 ++
 test/py/multiplexed_log.py  | 30 ---
 3 files changed, 74 insertions(+), 24 deletions(-)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 9c9426aebe10..3e162cafcc4a 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -249,6 +249,8 @@ def u_boot_console(request):
 
 tests_not_run = set()
 tests_failed = set()
+tests_xpassed = set()
+tests_xfailed = set()
 tests_skipped = set()
 tests_passed = set()
 
@@ -289,6 +291,14 @@ def cleanup():
 log.status_skipped('%d skipped' % len(tests_skipped))
 for test in tests_skipped:
 log.status_skipped('... ' + test)
+if tests_xpassed:
+log.status_xpass('%d xpass' % len(tests_xpassed))
+for test in tests_xpassed:
+log.status_xpass('... ' + test)
+if tests_xfailed:
+log.status_xfail('%d xfail' % len(tests_xfailed))
+for test in tests_xfailed:
+log.status_xfail('... ' + test)
 if tests_failed:
 log.status_fail('%d failed' % len(tests_failed))
 for test in tests_failed:
@@ -381,34 +391,42 @@ def pytest_runtest_protocol(item, nextitem):
 """
 
 reports = runtestprotocol(item, nextitem=nextitem)
-failed = None
-skipped = None
+
+failure_cleanup = False
+test_list = tests_passed
+msg = 'OK'
+msg_log = log.status_pass
 for report in reports:
 if report.outcome == 'failed':
-failed = report
+if hasattr(report, 'wasxfail'):
+test_list = tests_xpassed
+msg = 'XPASSED'
+msg_log = log.status_xpass
+else:
+failure_cleanup = True
+test_list = tests_failed
+msg = 'FAILED:\n' + str(report.longrepr)
+msg_log = log.status_fail
 break
 if report.outcome == 'skipped':
-if not skipped:
-skipped = report
-
-if failed:
+if hasattr(report, 'wasxfail'):
+failure_cleanup = True
+test_list = tests_xfailed
+msg = 'XFAILED:\n' + str(report.longrepr)
+msg_log = log.status_xfail
+break
+test_list = tests_skipped
+msg = 'SKIPPED:\n' + str(report.longrepr)
+msg_log = log.status_skipped
+
+if failure_cleanup:
 console.drain_console()
-tests_failed.add(item.name)
-elif skipped:
-tests_skipped.add(item.name)
-else:
-tests_passed.add(item.name)
+
+test_list.add(item.name)
 tests_not_run.remove(item.name)
 
 try:
-if failed:
-msg = 'FAILED:\n' + str(failed.longrepr)
-log.status_fail(msg)
-elif skipped:
-msg = 'SKIPPED:\n' + str(skipped.longrepr)
-log.status_skipped(msg)
-else:
-log.status_pass('OK')
+msg_log(msg)
 except:
 # If something went wrong with logging, it's better to let the test
 # process continue, which may report other exceptions that triggered
@@ -424,7 +442,7 @@ def pytest_runtest_protocol(item, nextitem):
 
 log.end_section(item.name)
 
-if failed:
+if failure_cleanup:
 console.cleanup_spawn()
 
 return reports
diff --git a/test/py/multiplexed_log.css b/test/py/multiplexed_log.css
index 50f7b9092983..f6240d52da66 100644
--- a/test/py/multiplexed_log.css
+++ b/test/py/multiplexed_log.css
@@ -83,6 +83,14 @@ pre {
 color: #00
 }
 
+.status-xfail {
+color: #ff7f00
+}
+
+.status-xpass {
+color: #ff7f00
+}
+
 .status-fail {
 color: #ff
 }
diff --git a/test/py/multiplexed_log.py b/test/py/multiplexed_log.py
index fd3a9231a819..69a577e57720 100644
--- a/test/py/multiplexed_log.py
+++ b/test/py/multiplexed_log.py
@@ -408,7 +408,7 @@ class Logfile(object):
 """Write a note to the log file describing test(s) which passed.
 
 Args:
-msg: A message describing passed test(s).
+msg: A message describing the passed test(s).
 
 Returns:
 Nothing.
@@ -420,7 +420,7 @@ class Logfile(object):
 """Write a note to the log file describing skipped test(s).
 
 Args:
-msg: A message describing passed test(s).
+msg: A message describing the skipped test(s).
 
 Returns:
 Nothing.
@@ -428,11 +428,35 @@ class Logfile(object):

[U-Boot] [PATCH 1/9] test/dm: clear unit test failure count each run

[Stephen Warren]

From: Stephen Warren 

The ut command prints a test failure count each time it is executed.
This is stored in a global variable which is never reset. Consequently,
the printed failure count accumulates across runs. Fix this by clearing
the counter each time "ut" is invoked.

Signed-off-by: Stephen Warren 
---
 test/dm/test-main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/dm/test-main.c b/test/dm/test-main.c
index 91bdda83ab36..f2e004814387 100644
--- a/test/dm/test-main.c
+++ b/test/dm/test-main.c
@@ -81,6 +81,8 @@ static int dm_test_main(const char *test_name)
struct unit_test *test;
int run_count;
 
+   uts->fail_count = 0;
+
/*
 * If we have no device tree, or it only has a root node, then these
 * tests clearly aren't going to work...
-- 
2.7.0

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

[U-Boot] [PATCH 2/9] test/py: fix spawn.expect multiple match handling

[Stephen Warren]

From: Stephen Warren 

Multiple patterns may be passed to spawn.expect(). The pattern which
matches at the earliest position should be designated as the match. This
aspect works correctly. When multiple patterns match at the same position,
priority should be given the the earliest entry in the list of patterns.
This aspect does not work correctly. This patch fixes it.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_spawn.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/u_boot_spawn.py b/test/py/u_boot_spawn.py
index d50807599027..7451455671b9 100644
--- a/test/py/u_boot_spawn.py
+++ b/test/py/u_boot_spawn.py
@@ -132,7 +132,7 @@ class Spawn(object):
 m = pattern.search(self.buf)
 if not m:
 continue
-if earliest_m and m.start() > earliest_m.start():
+if earliest_m and m.start() >= earliest_m.start():
 continue
 earliest_m = m
 earliest_pi = pi
-- 
2.7.0

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

[U-Boot] [PATCH 3/9] test.py: calculate bad patterns on change only

[Stephen Warren]

From: Stephen Warren 

A future patch will use the bad_patterns array in multiple places. Rather
than duplicating the code to calculate it, or even sharing it in a
function and simply calling it redundantly when nothing has changed, only
re-calculate the list when some change is made to it. This reduces work.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_console_base.py | 49 +-
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index c500fb3ae535..efb06cad0af0 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -23,6 +23,17 @@ pattern_stop_autoboot_prompt = re.compile('Hit any key to 
stop autoboot: ')
 pattern_unknown_command = re.compile('Unknown command \'.*\' - try \'help\'')
 pattern_error_notification = re.compile('## Error: ')
 
+PAT_ID = 0
+PAT_RE = 1
+
+bad_pattern_defs = (
+('spl_signon', pattern_u_boot_spl_signon),
+('main_signon', pattern_u_boot_main_signon),
+('stop_autoboot_prompt', pattern_stop_autoboot_prompt),
+('unknown_command', pattern_unknown_command),
+('error_notification', pattern_error_notification),
+)
+
 class ConsoleDisableCheck(object):
 """Context manager (for Python's with statement) that temporarily disables
 the specified console output error check. This is useful when deliberately
@@ -37,9 +48,11 @@ class ConsoleDisableCheck(object):
 
 def __enter__(self):
 self.console.disable_check_count[self.check_type] += 1
+self.console.eval_bad_patterns()
 
 def __exit__(self, extype, value, traceback):
 self.console.disable_check_count[self.check_type] -= 1
+self.console.eval_bad_patterns()
 
 class ConsoleBase(object):
 """The interface through which test functions interact with the U-Boot
@@ -77,16 +90,18 @@ class ConsoleBase(object):
 self.prompt = self.config.buildconfig['config_sys_prompt'][1:-1]
 self.prompt_escaped = re.escape(self.prompt)
 self.p = None
-self.disable_check_count = {
-'spl_signon': 0,
-'main_signon': 0,
-'unknown_command': 0,
-'error_notification': 0,
-}
+self.disable_check_count = {pat[PAT_ID]: 0 for pat in bad_pattern_defs}
+self.eval_bad_patterns()
 
 self.at_prompt = False
 self.at_prompt_logevt = None
 
+def eval_bad_patterns(self):
+self.bad_patterns = [pat[PAT_RE] for pat in bad_pattern_defs \
+if self.disable_check_count[pat[PAT_ID]] == 0]
+self.bad_pattern_ids = [pat[PAT_ID] for pat in bad_pattern_defs \
+if self.disable_check_count[pat[PAT_ID]] == 0]
+
 def close(self):
 """Terminate the connection to the U-Boot console.
 
@@ -148,20 +163,6 @@ class ConsoleBase(object):
 self.at_prompt_logevt != self.logstream.logfile.cur_evt:
 self.logstream.write(self.prompt, implicit=True)
 
-bad_patterns = []
-bad_pattern_ids = []
-if (self.disable_check_count['spl_signon'] == 0):
-bad_patterns.append(pattern_u_boot_spl_signon)
-bad_pattern_ids.append('SPL signon')
-if self.disable_check_count['main_signon'] == 0:
-bad_patterns.append(pattern_u_boot_main_signon)
-bad_pattern_ids.append('U-Boot main signon')
-if self.disable_check_count['unknown_command'] == 0:
-bad_patterns.append(pattern_unknown_command)
-bad_pattern_ids.append('Unknown command')
-if self.disable_check_count['error_notification'] == 0:
-bad_patterns.append(pattern_error_notification)
-bad_pattern_ids.append('Error notification')
 try:
 self.at_prompt = False
 if send_nl:
@@ -175,18 +176,18 @@ class ConsoleBase(object):
 continue
 chunk = re.escape(chunk)
 chunk = chunk.replace('\\\n', '[\r\n]')
-m = self.p.expect([chunk] + bad_patterns)
+m = self.p.expect([chunk] + self.bad_patterns)
 if m != 0:
 self.at_prompt = False
 raise Exception('Bad pattern found on console: ' +
-bad_pattern_ids[m - 1])
+self.bad_pattern_ids[m - 1])
 if not wait_for_prompt:
 return
-m = self.p.expect([self.prompt_escaped] + bad_patterns)
+m = self.p.expect([self.prompt_escaped] + self.bad_patterns)
 if m != 0:
 self.at_prompt = False
 raise Exception('Bad pattern found on console: ' +
-bad_pattern_ids[m - 1])
+self.bad_pattern_ids[m - 1])
 self.at_prompt = True
 self.at_prompt_logevt = 

[U-Boot] [PATCH 4/9] test/py: check for bad patterns everywhere we wait

[Stephen Warren]

From: Stephen Warren 

Currently, bad patterns are only honored when executing a shell command.
Other cases, such as the initial boot-up of U-Boot or when interacting
with command output rather than gathering all output prior to the shell
prompt, do not currently look for bad patterns in console output. This
patch makes sure that bad patterns are honored everywhere.

One benefit of this change is that if U-Boot sandbox fails to start up,
the error message it emits can be caught immediately, rather than relying
on a (long) timeout when waiting for the expected signon message and/or
command prompt.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_console_base.py | 26 +++---
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index efb06cad0af0..71a00e863385 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -231,7 +231,10 @@ class ConsoleBase(object):
 
 if type(text) == type(''):
 text = re.escape(text)
-self.p.expect([text])
+m = self.p.expect([text] + self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])
 
 def drain_console(self):
 """Read from and log the U-Boot console for a short time.
@@ -298,8 +301,14 @@ class ConsoleBase(object):
 self.p.timeout = 3
 self.p.logfile_read = self.logstream
 if self.config.buildconfig.get('CONFIG_SPL', False) == 'y':
-self.p.expect([pattern_u_boot_spl_signon])
-self.p.expect([pattern_u_boot_main_signon])
+m = self.p.expect([pattern_u_boot_spl_signon] + 
self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])
+m = self.p.expect([pattern_u_boot_main_signon] + self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])
 signon = self.p.after
 build_idx = signon.find(', Build:')
 if build_idx == -1:
@@ -307,12 +316,15 @@ class ConsoleBase(object):
 else:
 self.u_boot_version_string = signon[:build_idx]
 while True:
-match = self.p.expect([self.prompt_escaped,
-   pattern_stop_autoboot_prompt])
-if match == 1:
+m = self.p.expect([self.prompt_escaped,
+pattern_stop_autoboot_prompt] + self.bad_patterns)
+if m == 0:
+break
+if m == 1:
 self.p.send(chr(3)) # CTRL-C
 continue
-break
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 2])
 self.at_prompt = True
 self.at_prompt_logevt = self.logstream.logfile.cur_evt
 except Exception as ex:
-- 
2.7.0

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

[U-Boot] [PATCH 5/9] test/py: detect another "bad pattern" in console output

[Stephen Warren]

From: Stephen Warren 

Many error situations in U-Boot print the message:
### ERROR ### Please RESET the board ###

Add this to the list of bad patterns the test system detects. One
practical advantage of this change is to detect the case where sandbox
is told to use a particular DTB file, and the file cannot be opened.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_console_base.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index 71a00e863385..392f8cb88532 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -22,6 +22,7 @@ pattern_u_boot_main_signon = re.compile('(U-Boot 
\\d{4}\\.\\d{2}-[^\r\n]*)')
 pattern_stop_autoboot_prompt = re.compile('Hit any key to stop autoboot: ')
 pattern_unknown_command = re.compile('Unknown command \'.*\' - try \'help\'')
 pattern_error_notification = re.compile('## Error: ')
+pattern_error_please_reset = re.compile('### ERROR ### Please RESET the board 
###')
 
 PAT_ID = 0
 PAT_RE = 1
@@ -32,6 +33,7 @@ bad_pattern_defs = (
 ('stop_autoboot_prompt', pattern_stop_autoboot_prompt),
 ('unknown_command', pattern_unknown_command),
 ('error_notification', pattern_error_notification),
+('error_please_reset', pattern_error_please_reset),
 )
 
 class ConsoleDisableCheck(object):
-- 
2.7.0

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

[U-Boot] [PATCH 7/9] test/py: pass test DTB to sandbox

[Stephen Warren]

From: Stephen Warren 

This is required for at least "ut dm" to operate correctly.

Signed-off-by: Stephen Warren 
---
 test/py/u_boot_console_sandbox.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/test/py/u_boot_console_sandbox.py 
b/test/py/u_boot_console_sandbox.py
index 267f8b06508b..bbf41e788ba3 100644
--- a/test/py/u_boot_console_sandbox.py
+++ b/test/py/u_boot_console_sandbox.py
@@ -39,7 +39,12 @@ class ConsoleSandbox(ConsoleBase):
 A u_boot_spawn.Spawn object that is attached to U-Boot.
 """
 
-return Spawn([self.config.build_dir + '/u-boot'])
+cmd = [
+self.config.build_dir + '/u-boot',
+'-d',
+self.config.build_dir + '/arch/sandbox/dts/test.dtb'
+]
+return Spawn(cmd)
 
 def kill(self, sig):
 """Send a specific Unix signal to the sandbox process.
-- 
2.7.0

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

[U-Boot] [PATCH] pci: gate print info of reading vender id with CONFIG_DM_PCI

[Gong Qianyu]

From: Mingkai Hu 

Referring to 'commit ff3e077bd23c ("dm: pci: Add a uclass for PCI")'.

For legacy PCIe driver, it needs loop to read the vender_id from
devie 0 to devie 255 to check if there is device available.
Reading non-existen device will trigger the "Cannot read bus
configuration: -1" information.

Signed-off-by: Mingkai Hu 
Signed-off-by: Gong Qianyu 
---
 common/cmd_pci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/common/cmd_pci.c b/common/cmd_pci.c
index 4e0951f..d94f90d 100644
--- a/common/cmd_pci.c
+++ b/common/cmd_pci.c
@@ -324,7 +324,9 @@ void pciinfo(int bus_num, int short_pci_listing)
unsigned char header_type;
unsigned short vendor_id;
pci_dev_t dev;
+#ifdef CONFIG_DM_PCI
int ret;
+#endif
 
if (!hose)
return;
@@ -348,10 +350,14 @@ void pciinfo(int bus_num, int short_pci_listing)
if (pci_skip_dev(hose, dev))
continue;
 
+#ifdef CONFIG_DM_PCI
ret = pci_read_config_word(dev, PCI_VENDOR_ID,
   _id);
if (ret)
goto error;
+#else
+   pci_read_config_word(dev, PCI_VENDOR_ID, _id);
+#endif
if ((vendor_id == 0x) || (vendor_id == 0x))
continue;
 
@@ -373,8 +379,10 @@ void pciinfo(int bus_num, int short_pci_listing)
}
 
return;
+#ifdef CONFIG_DM_PCI
 error:
printf("Cannot read bus configuration: %d\n", ret);
+#endif
 }
 #endif
 
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH v3 3/7] SECURE_BOOT: split the secure boot functionality in two parts

[york sun]

On 01/22/2016 03:10 AM, Aneesh Bansal wrote:
> There are two phases in Secure Boot
> 1. ISBC: In BootROM, validate the BootLoader (U-Boot).
> 2. ESBC: In U-Boot, continuing the Chain of Trust by
>  validating and booting LINUX.
> 
> For ESBC phase, there is no difference in SoC's based on ARM or PowerPC
> cores.
> 
> But the exit conditions after ISBC phase i.e. entry conditions for
> U-Boot are different for ARM and PowerPC.
> PowerPC:
> 
> If Secure Boot is executed, a separate U-Boot target is required which
> must be compiled with a diffrent Text Base as compared to Non-Secure Boot.
> There are some LAW and TLB settings which are required specifically for
> Secure Boot scenario.
> 
> ARM:
> 
> ARM based SoC's have a fixed memory map and exit conditions from BootROM
> are same irrespective of boot mode (Secure or Non-Secure).
> 
> Thus the current Secure Boot functionlity has been split into two parts:
> 
> CONFIG_CHAIN_OF_TRUST
> 
> This will have the following functionality as part of U-Boot:
> 1. Enable commands like esbc_validate, esbc_halt
> 2. Change the environment settings based on bootmode (determined at run time):
>  - If bootmode is non-secure, no change
>  - If bootmode is secure, set the following:
>  - bootdelay = 0 (Don't give boot prompt)
>  - bootcmd = Validate and execute the bootscript.
> 
> CONFIG_SECURE_BOOT
> =
> This is defined only for creating a different compile time target for secure 
> boot.
> 
> Traditionally, both these functionalities were defined under 
> CONFIG_SECURE_BOOT
> This patch is aimed at removing the requirement for a separate Secure Boot 
> target
> for ARM based SoC's. CONFIG_CHAIN_OF_TRUST will be defined and boot mode will 
> be
> determine at run time.
> 
> Another Security Requirement for running CHAIN_OF_TRUST is that U-Boot 
> environemnt
> must not be picked from flash/external memory. This cannot be done based on 
> bootmode
> at run time in current U-Boot architecture. Once this dependency is resolved, 
> no separate
> SECURE_BOOT target will be required for ARM based SoC's.
> 
> Currently, the only code under CONFIG_SECURE_BOOT for ARM SoC's is defining
> CONFIG_ENV_IS_NOWHERE
> 
> Signed-off-by: Aneesh Bansal 
> ---
> Changes in v3:
> None
> 
> Changes in v2:
> CONFIG_ENV_IS_NOWHERE is defined for Secure Boot
> 
>  arch/arm/include/asm/fsl_secure_boot.h |  16 ++--
>  arch/powerpc/include/asm/fsl_secure_boot.h |  41 +-
>  include/config_fsl_chain_trust.h   | 101 +
>  include/config_fsl_secboot.h   | 116 
> -
>  4 files changed, 135 insertions(+), 139 deletions(-)
>  create mode 100644 include/config_fsl_chain_trust.h
>  delete mode 100644 include/config_fsl_secboot.h
> 

Change subject prefix to "secure_boot:". Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH v3 7/7] SECURE_BOOT: change error handler for esbc_validate

[york sun]

On 01/22/2016 03:10 AM, Aneesh Bansal wrote:
> In case of error while executing esbc_validate command, SNVS
> transition and issue of reset is required only for secure-boot.
> If boot mode is non-secure, this is not required.
> 
> Similarly, esbc_halt command which puts the core in Spin Loop
> is applicable only for Secure Boot.
> 
> Signed-off-by: Aneesh Bansal 
> ---
> Changes in v3:
> None
> 
> Changes in v2:
> None (Changed the Sign-Off with New E-Mail ID)
> 
>  board/freescale/common/cmd_esbc_validate.c | 7 ++-
>  board/freescale/common/fsl_validate.c  | 7 +++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 

Change subject prefix to "secure_boot:".
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 5/7] driver: net: ldpaa: Increase num of buffers for a pool

[york sun]

On 12/24/2015 02:03 AM, Prabhakar Kushwaha wrote:
> Management Complex FW 9.0 set the hardware depletion to be 20 buffers
> in order to support multiple pools in DPNI. This requires driver to fill
> the pool with at least 21 to be able to receive frames.
> 
> So, Increase number of buffers for a pool.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 6/7] driver: net: ldpaa: Add debug info of printing DPMAC stats

[york sun]

On 12/24/2015 02:03 AM, Prabhakar Kushwaha wrote:
> Add debug information prints to provide DPMAC statistics
>  - Number of bytes received
>  - Number of received and discard frames
>  - Number of bytes transferred
>  - Number of frames transferred
>  etc.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 78 
> +++
>  1 file changed, 78 insertions(+)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [Patch V7 1/4] spi: fsl_qspi: fix compile warning for 64-bit platform

[york sun]

On 01/25/2016 11:15 PM, Gong Qianyu wrote:
> From: Gong Qianyu 
> 
> This patch fixes the following compile warning:
> drivers/spi/fsl_qspi.c: In function 'fsl_qspi_probe':
> drivers/spi/fsl_qspi.c:937:15:
>   warning: cast to pointer from integer of different size
>[-Wint-to-pointer-cast]
>   priv->regs = (struct fsl_qspi_regs *)plat->reg_base;
>^
> Just make the cast explicit.
> 
> Signed-off-by: Gong Qianyu 
> ---
> V6-V7:
>  - No change.
> V5:
>  - Use uintptr_t instead of unsigned long.
> V4:
>  - Revise the commit message.
> V2-V3:
>  - No change.
> 
>  drivers/spi/fsl_qspi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 7/7] driver: net: fsl-mc: Remove portal id hard-coding

[york sun]

On 12/24/2015 02:03 AM, Prabhakar Kushwaha wrote:
> Management Complex firmware 9.0 has fixed the issue of dprc_destroy_container
> i.e. the used portal is not return to the free pool. Which was resulting in
> error ethernet driver want to use this portal via either DPL or dynamically
> in Linux.
> 
> So, Remove hard-coding of portal id.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/fsl-mc/mc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 1/7] driver: net: fsl-mc: Add version check for MC objects

[york sun]

On 12/24/2015 02:02 AM, Prabhakar Kushwaha wrote:
> Check and compare version of management  complex's object with the version
> supported by Freescale ldpaa2 ethernet driver.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/fsl-mc/mc.c   | 51 
> ++-
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 28 +
>  2 files changed, 78 insertions(+), 1 deletion(-)

Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 4/7] driver: net: ldpaa: Report back only error frames for tx

[york sun]

On 12/24/2015 02:03 AM, Prabhakar Kushwaha wrote:
> Management Complex FW 9.0 puts a new requirement to provide Tx confirmation
> and error queue configuration by calling dpni_set_tx_conf API.
> 
> Configure report of only error frames for a tx frame.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 12 
>  1 file changed, 12 insertions(+)
> 

Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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

Re: [U-Boot] [PATCH 3/7] driver: net: fsl-mc: Prepare extended cfg for DPNI create

[york sun]

On 12/24/2015 02:03 AM, Prabhakar Kushwaha wrote:
> Management Complex FW 9.0 puts a new requirement to prepare extended
> parameters which should be provided as input in dpni_create. extended
> parameters includes traffic class and IP reassembly configurations.
> 
> So prepare extended parameters with default "0" as input for dpni_create.
> 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  drivers/net/fsl-mc/mc.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

Slightly reformat commit message.
Applied to u-boot-fsl-qoriq master. Awaiting upstream.

Thanks.

York

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