Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

[Hans de Goede]

Hi,

On 01-06-15 22:46, Tom Rini wrote:

On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote:

Hi,

On 01-06-15 20:12, Ian Campbell wrote:

On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:

The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
using the same defconfig (and dts on the kernel side) for both models.
Unfortunately this does not work for the otg controller, on the M9 this
is routed to a micro-usb connector on the outside, while as on the
A1000G-quad it is connected to an usb to sata bridge.

This commit adds a new defconfig for the Mele-A1000G-quad to allow using
different otg controller settings on the 2 boards.

Signed-off-by: Hans de Goede hdego...@redhat.com
diff --git a/configs/Mele_A1000G_quad_defconfig 
b/configs/Mele_A1000G_quad_defconfig
new file mode 100644
index 000..b93dcf5
--- /dev/null
+++ b/configs/Mele_A1000G_quad_defconfig
@@ -0,0 +1,24 @@
+# The Mele A1000G quad is yet another Allwinnner based Android top set box
+# from Mele.
+#
+# It uses the same case as the original Mele A1000 and the same PCB as the M9,
+# the  USM sata storage slot is connected via anusb to sata bridge connected to
+# the otg controller, this renders the micro USB B receptacle non functional.
+#
+# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
+# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
+# RTL R8188EU (USB) wifi and a full size sdcard slot


Have you seen the thread Clean all defconfigs with savedefconfig which
we were copied on today? It seems that these comments are subject to
automated cleansing :-/


Explictly adding Tom to the list of recipients

Tom, do we really want some autofoobar tool to mangle our defconfigs? Is there
a way we can opt out of this ?

Reasons to opt out:

1) Having comments like the one above on top of the defconfig files makes
it much easier for people to check if they are selecting the right defconfig

2) We deliberately duplicate some settings in defconfig files even though
they are the default since new users submitting new boards tend to copy and
paste an existing defconfig of a similar board and this way they have a short
list of settings to check against the actual board, because their board may
not be using the reference design pins which we use as defaults ...

So personally as sunxi maintainer I would like to opt out of this automatic
destruction of useful info in our defconfigs ...


So, historically people have put a lot of odds and ends info into either
include/configs/board.h or boards/vendor/board/board.c.  With Kconfig
we're moving away from the former and with things like sunxi where we
just slightly tweak some parameters to run on many boards we don't have
the latter the question is where to place otherwise generally useful
info.

The problem, to expand on what I said in the other thread, is that
*_defconfig is treated as an auto-generated file in Kbuild projects (I
know the kernel and I'm pretty sure elsewhere too).  This is only going
to get more noticable as we convert things over to real Kconfig choices,
meaning that if we opt-out of changing sunxi configs they're going to
get broken or make the conversion harder for everyone else.

We should be able to add say board/sunxi/README.txt and keep it
formatted such that new entries go on the bottom and have a predefined
separator at the end so that adding more boards doesn't conflict.


If we stuff everything in one file people need to match which board
description belongs to which defconfig manually at which point
we might just as well point them to the linux-sunxi.org wiki
which has all this info + actual pictures of the devices.

So if there is no way to store this info in the defconfigs lets
just leave it out and will point people to the wiki.

Regards,

Hans


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

Re: [U-Boot] [PATCH] ARM: phytec: pcm051: drop unused CONFIG_NET_MULTI

[Lars Poeschel]

On Mon, Jun 01, 2015 at 01:34:12PM -0500, Joe Hershberger wrote:
 Hi Lars,
 
 On Mon, Jun 1, 2015 at 9:59 AM,  poesc...@lemonage.de wrote:
  From: Lars Poeschel poesc...@lemonage.de
 
  Drop unused CONFIG_NET_MULTI.
  Also drop CONFIG_USE_IRQ, that is not used either.
 
  Signed-off-by: Lars Poeschel poesc...@lemonage.de
  ---
   include/configs/pcm051.h | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)
 
  diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
  index c0bb227..eef3269 100644
  --- a/include/configs/pcm051.h
  +++ b/include/configs/pcm051.h
  @@ -163,10 +163,8 @@
   #define CONFIG_USB_ETH_RNDIS
   #endif /* CONFIG_MUSB_GADGET */
 
  -/* Unsupported features */
  -#undef CONFIG_USE_IRQ
 
 These are unrelated changes. They should be two separate patches.
 
 Also, you say this is unused, but you are editing an ARM board and it
 seems that the arch/arm/lib/ source does refer to this. Are you sure
 it is unused? If so, Please make a separate patch with more
 explanation instead of adding it into another patch as a me-too.

Well, I am quite shure this not needed anymore. This is an undef and
CONFIG_USE_IRQ is not defined in the include path before. I just tested
it and with or without the undef the same code is compiled.
But your are right: These changes are not related. I will make two
seperate patches.

  -#define CONFIG_NET_MULTI
 
 Since this is not used anywhere, can you remove it from all of the
 configs that still define it all in the same patch?

Yes, I will do that.

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

[U-Boot] [PATCH v2 1/2] ARM: phytec: pcm051: Remove unneeded CONFIG_USE_IRQ

[poeschel]

From: Lars Poeschel poesc...@lemonage.de

The config for pcm051 still undef'd CONFIG_USE_IRQ. This is not
needed any more since it is not defined in the whole include path
before.

Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
 include/configs/pcm051.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
index c0bb227..601c919 100644
--- a/include/configs/pcm051.h
+++ b/include/configs/pcm051.h
@@ -163,9 +163,6 @@
 #define CONFIG_USB_ETH_RNDIS
 #endif /* CONFIG_MUSB_GADGET */
 
-/* Unsupported features */
-#undef CONFIG_USE_IRQ
-
 #define CONFIG_NET_MULTI
 #define CONFIG_PHY_GIGE
 #define CONFIG_PHYLIB
-- 
2.1.4

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

Re: [U-Boot] [PATCH] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Simon Glass]

Hi Bin,

On 2 June 2015 at 08:41, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Tue, Jun 2, 2015 at 6:44 PM, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Tue, Jun 2, 2015 at 6:40 PM, Bin Meng bmeng...@gmail.com wrote:
 The following error is observed on QEMU x86.

 = print ipaddr
 ipaddr=192.168.178.66
 = ping 192.168.178.1
 *** ERROR: `ipaddr' not set
 ping failed; host 192.168.178.1 is not alive

 The issue was introduced in commit fd30563. Adding CMD_NET to
 defconfig resolves this. Also reorder the config options to
 match the order in Kconfig.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  configs/qemu-x86_defconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
 index a5251b5..07b5176 100644
 --- a/configs/qemu-x86_defconfig
 +++ b/configs/qemu-x86_defconfig
 @@ -1,9 +1,9 @@
  CONFIG_X86=y
  CONFIG_VENDOR_EMULATION=y
  CONFIG_TARGET_QEMU_X86=y
 +CONFIG_GENERATE_PIRQ_TABLE=y
 +CONFIG_CMD_NET=y
  CONFIG_OF_CONTROL=y
 -CONFIG_OF_SEPARATE=y
  CONFIG_VIDEO_VESA=y
  CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
  CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 -CONFIG_GENERATE_PIRQ_TABLE=y
 --

 After Joe's pull request [1] get applied by Tom, you can rebase
 u-boot-x86/testing branch and apply this one to fix the qemu
 networking issue. Thanks!

 [1] http://patchwork.ozlabs.org/patch/479136/


 I see Joe's pull request has been applied, but sorry I've noticed that
 this patch has some dependencies on the qemu v2 patch series I am
 working on. Please ignore this and I will resend it as part of my qemu
 v2 patch series soon. Sorry about that.

OK I have it setting in x86/testing. Please let me know what commits
need changing, etc.

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

Re: [U-Boot] [PATCH] spi: cadence_qspi: Fix the indirect ahb trigger address setting

[Graham Moore]

Hello,

OK, first of all, I'm not the original author, just the one who has to 
fix it nowadays.  There are many things that have confused me in this 
driver.


The mask issue seems familiar, let me look at it, and I'll get back to you.

-Graham

On 06/02/2015 11:11 AM, Vikas MANOCHA wrote:

Hi Graham,


-Original Message-
From: Stefan Roese [mailto:s...@denx.de]
Sent: Monday, June 01, 2015 4:34 AM
To: Vikas MANOCHA; u-boot@lists.denx.de; Graham Moore
Cc: Dinh Nguyen; Marek Vasut
Subject: Re: [PATCH] spi: cadence_qspi: Fix the indirect ahb trigger address
setting

Hi Vikas,

On 29.05.2015 18:53, vikasm wrote:

On 05/28/2015 11:20 PM, Stefan Roese wrote:

Hi Vikas,

(added Dinh, Graham and Marek to Cc)

On 29.05.2015 03:22, Vikas Manocha wrote:

Trigger base address can be set to the spi flash address without any
masking, here is the explanation of the register.

QSPI_IND_AHB_ADDR_TRIGGER :
Trigger Address is the base address that is used by the AHB
controller for indirect accesses. When the incoming AHB access
address matches a range of addresses from this trigger address to
the trigger address + 15, then the AHB request is completed by

fetching/storing data from/to the Controllers SRAM.


Signed-off-by: Vikas Manocha vikas.mano...@st.com
---
drivers/spi/cadence_qspi_apb.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c
b/drivers/spi/cadence_qspi_apb.c index 00a115f..855e5c7 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -50,7 +50,6 @@
#define CQSPI_INST_TYPE_QUAD(2)

#define CQSPI_STIG_DATA_LEN_MAX (8)
-#define CQSPI_INDIRECTTRIGGER_ADDR_MASK(0xF)

#define CQSPI_DUMMY_CLKS_PER_BYTE   (8)
#define CQSPI_DUMMY_BYTES_MAX   (4)
@@ -697,8 +696,7 @@ int

cadence_qspi_apb_indirect_read_setup(struct cadence_spi_platdata *plat,

addr_bytes = cmdlen - 1;

/* Setup the indirect trigger address */
-   writel(((u32)plat-ahbbase 

CQSPI_INDIRECTTRIGGER_ADDR_MASK),

-  plat-regbase + CQSPI_REG_INDIRECTTRIGGER);
+   writel((u32)plat-ahbbase, plat-regbase +
+CQSPI_REG_INDIRECTTRIGGER);

/* Configure SRAM partition for read. */
writel(CQSPI_REG_SRAM_PARTITION_RD, plat-regbase + @@ -

798,8

+796,7 @@ int cadence_qspi_apb_indirect_write_setup(struct

cadence_spi_platdata *plat,

return -EINVAL;
}
/* Setup the indirect trigger address */
-   writel(((u32)plat-ahbbase 

CQSPI_INDIRECTTRIGGER_ADDR_MASK),

-  plat-regbase + CQSPI_REG_INDIRECTTRIGGER);
+   writel((u32)plat-ahbbase, plat-regbase +
+CQSPI_REG_INDIRECTTRIGGER);

Might I ask on which SoC you are using this driver? Which problem are
you experiencing exactly?


I am using ST's soc stv0991. The spi flash memory is mapped at address
0x4000_. By Masking with 0xF_, the value to be loaded in the
indirect trigger register becomes zero  then spi read/write does not
work. By removing or changing the mask to 0x_, the loaded
value in indirect trigger register is 0x4000_  spi read/write works fine.

It should be same of socfpga also after masking with 0xF_,
wondering how it works there.


Yes, I'm wondering a bit myself. Thats why I added Graham to Cc as he is the
author of the original driver. And knows this far better than I do.


No masking is done in the driver while polling fifo for read/write,
plat-ahbbase was used directly. Any idea why this masking was done
for ahb trigger base register?


Graham? Do you have any insight here please?


Any idea ?

Rgds,
Vikas



Thanks,
Stefan



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

Re: [U-Boot] [RFC PATCH 2/2] x86: fsp: Move FspInitEntry call to board_init_f()

[Andrew Bradford]

Hi Bin,

On 06/01 20:31, Bin Meng wrote:
 The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
 It worked pretty well but looks not that good. Apart from doing too
 much work than just enabling CAR, it cannot read the configuration
 data from device tree at that time. Now we want to move it a little
 bit later as part of init_sequence_f[] being called by board_init_f().
 This way it looks and works better in the U-Boot initialization path.
 
 Due to FSP's design, after calling FspInitEntry it will not return to
 its caller, instead it jumps to a continuation function which is given
 by bootloader with a new stack in system memory. The original stack in
 the CAR is gone, but its content is perserved by FSP and described by
 a bootloader temporary memory HOB. Technically we can recover anything
 we had before in the previous stack, but that is way too complicated.
 To make life much easier, in the FSP continuation routine we just
 simply call fsp_init_done() and jump back to car_init_ret() to redo
 the whole board_init_f() initialization, but this time with a non-zero
 HOB list pointer saved in U-Boot's global data so that we can bypass
 the FspInitEntry for the second time.
 
 Signed-off-by: Bin Meng bmeng...@gmail.com
 
 ---
 
  arch/x86/cpu/start.S  |  6 +-
  arch/x86/include/asm/u-boot-x86.h |  4 
  arch/x86/lib/fsp/fsp_car.S| 26 +-
  arch/x86/lib/fsp/fsp_common.c |  8 
  common/board_f.c  |  3 +++
  5 files changed, 25 insertions(+), 22 deletions(-)
 
 diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
 index 2e5f9da..00e585e 100644
 --- a/arch/x86/cpu/start.S
 +++ b/arch/x86/cpu/start.S
 @@ -116,12 +116,16 @@ car_init_ret:
   rep stosb
  
  #ifdef CONFIG_HAVE_FSP
 + test%esi, %esi
 + jz  skip_hob
 +
   /* Store HOB list */
   movl%esp, %edx
   addl$GD_HOB_LIST, %edx
   movl%esi, (%edx)
 -#endif
  
 +skip_hob:
 +#endif
   /* Setup first parameter to setup_gdt, pointer to global_data */
   movl%esp, %eax
  
 diff --git a/arch/x86/include/asm/u-boot-x86.h 
 b/arch/x86/include/asm/u-boot-x86.h
 index faa5182..9ee4104 100644
 --- a/arch/x86/include/asm/u-boot-x86.h
 +++ b/arch/x86/include/asm/u-boot-x86.h
 @@ -54,6 +54,10 @@ u32 isa_map_rom(u32 bus_addr, int size);
  /* arch/x86/lib/... */
  int video_bios_init(void);
  
 +#ifdef CONFIG_HAVE_FSP
 +int x86_fsp_init(void);
 +#endif
 +
  void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
  void board_init_f_r(void) __attribute__ ((noreturn));
  
 diff --git a/arch/x86/lib/fsp/fsp_car.S b/arch/x86/lib/fsp/fsp_car.S
 index 5e09568..afbf3f9 100644
 --- a/arch/x86/lib/fsp/fsp_car.S
 +++ b/arch/x86/lib/fsp/fsp_car.S
 @@ -56,28 +56,10 @@ temp_ram_init_ret:
  
   /* stack grows down from top of CAR */
   movl%edx, %esp
 + subl$4, %esp
  
 - /*
 -  * TODO:
 -  *
 -  * According to FSP architecture spec, the fsp_init() will not return
 -  * to its caller, instead it requires the bootloader to provide a
 -  * so-called continuation function to pass into the FSP as a parameter
 -  * of fsp_init, and fsp_init() will call that continuation function
 -  * directly.
 -  *
 -  * The call to fsp_init() may need to be moved out of the car_init()
 -  * to cpu_init_f() with the help of some inline assembly codes.
 -  * Note there is another issue that fsp_init() will setup another stack
 -  * using the fsp_init parameter stack_top after DRAM is initialized,
 -  * which means any data on the previous stack (on the CAR) gets lost
 -  * (ie: U-Boot global_data). FSP is supposed to support such scenario,
 -  * however it does not work. This should be revisited in the future.
 -  */
 - movl$CONFIG_FSP_TEMP_RAM_ADDR, %eax
 - xorl%edx, %edx
 - xorl%ecx, %ecx
 - callfsp_init
 + xor %esi, %esi
 + jmp car_init_done
  
  .global fsp_init_done
  fsp_init_done:
 @@ -86,6 +68,8 @@ fsp_init_done:
* Save eax to esi temporarily.
*/
   movl%eax, %esi
 +
 +car_init_done:
   /*
* Re-initialize the ebp (BIST) to zero, as we already reach here
* which means we passed BIST testing before.
 diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
 index 001494d..5b25632 100644
 --- a/arch/x86/lib/fsp/fsp_common.c
 +++ b/arch/x86/lib/fsp/fsp_common.c
 @@ -46,3 +46,11 @@ void board_final_cleanup(void)
  
   return;
  }
 +
 +int x86_fsp_init(void)
 +{
 + if (!gd-arch.hob_list)
 + fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, NULL);
 +
 + return 0;
 +}
 diff --git a/common/board_f.c b/common/board_f.c
 index fbbad1b..21be26f 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -753,6 +753,9 @@ static init_fnc_t init_sequence_f[] = {
  #ifdef CONFIG_OF_CONTROL
   fdtdec_setup,
  #endif
 +#if 

[U-Boot] [RFC PATCH 1/3] ARM: ts4800: add basic board support

[Damien Riegel]

From: Lucile Quirion lucile.quir...@savoirfairelinux.com

This commit adds basic support including:
MMC, Serial console, TS4800 watchdog

The config use CONFIG_SKIP_LOWLEVEL_INIT as U-boot is used as a second
stage bootloader.

Signed-off-by: Lucile Quirion lucile.quir...@savoirfairelinux.com
Cc: Stefano Babic sba...@denx.de
---
 arch/arm/Kconfig |   5 ++
 board/technologic/ts4800/Kconfig |  15 
 board/technologic/ts4800/MAINTAINERS |   6 ++
 board/technologic/ts4800/Makefile|   7 ++
 board/technologic/ts4800/ts4800.c| 155 
 configs/ts4800_defconfig |   2 +
 include/configs/ts4800.h | 170 +++
 7 files changed, 360 insertions(+)
 create mode 100644 board/technologic/ts4800/Kconfig
 create mode 100644 board/technologic/ts4800/MAINTAINERS
 create mode 100644 board/technologic/ts4800/Makefile
 create mode 100644 board/technologic/ts4800/ts4800.c
 create mode 100644 configs/ts4800_defconfig
 create mode 100644 include/configs/ts4800.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2985e6e..e821eb9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -641,6 +641,10 @@ config TARGET_SNOWBALL
bool Support snowball
select CPU_V7
 
+config TARGET_TS4800
+   bool Support TS4800
+   select CPU_V7
+
 config TARGET_U8500_HREF
bool Support u8500_href
select CPU_V7
@@ -959,6 +963,7 @@ source board/toradex/colibri_pxa270/Kconfig
 source board/toradex/colibri_vf/Kconfig
 source board/tqc/tqma6/Kconfig
 source board/trizepsiv/Kconfig
+source board/technologic/ts4800/Kconfig
 source board/ttcontrol/vision2/Kconfig
 source board/udoo/Kconfig
 source board/vpac270/Kconfig
diff --git a/board/technologic/ts4800/Kconfig b/board/technologic/ts4800/Kconfig
new file mode 100644
index 000..a28d5e4
--- /dev/null
+++ b/board/technologic/ts4800/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_TS4800
+
+config SYS_BOARD
+   default ts4800
+
+config SYS_VENDOR
+   default technologic
+
+config SYS_SOC
+   default mx5
+
+config SYS_CONFIG_NAME
+   default ts4800
+
+endif
diff --git a/board/technologic/ts4800/MAINTAINERS 
b/board/technologic/ts4800/MAINTAINERS
new file mode 100644
index 000..e013ee4
--- /dev/null
+++ b/board/technologic/ts4800/MAINTAINERS
@@ -0,0 +1,6 @@
+TS4800 BOARD
+M: Lucile Quirion lucile.quir...@savoirfairelinux.com
+S: Maintained
+F: board/ts/ts4800/
+F: include/configs/ts4800.h
+F: configs/ts4800_defconfig
diff --git a/board/technologic/ts4800/Makefile 
b/board/technologic/ts4800/Makefile
new file mode 100644
index 000..e9f1a37
--- /dev/null
+++ b/board/technologic/ts4800/Makefile
@@ -0,0 +1,7 @@
+#
+# (C) Copyright 2015 Savoir-faire Linux
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += ts4800.o
diff --git a/board/technologic/ts4800/ts4800.c 
b/board/technologic/ts4800/ts4800.c
new file mode 100644
index 000..e49f185
--- /dev/null
+++ b/board/technologic/ts4800/ts4800.c
@@ -0,0 +1,155 @@
+/*
+ * (C) Copyright 2015 Savoir-faire Linux Inc.
+ *
+ * Derived from MX51EVK code by
+ *   Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/gpio.h
+#include asm/arch/imx-regs.h
+#include asm/arch/iomux-mx51.h
+#include asm/errno.h
+#include asm/arch/sys_proto.h
+#include asm/arch/crm_regs.h
+#include asm/arch/clock.h
+#include asm/imx-common/mx5_video.h
+#include mmc.h
+#include fsl_esdhc.h
+#include mc13892.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_FSL_ESDHC
+struct fsl_esdhc_cfg esdhc_cfg[2] = {
+   {MMC_SDHC1_BASE_ADDR},
+   {MMC_SDHC2_BASE_ADDR},
+};
+#endif
+
+int dram_init(void)
+{
+   /* dram_init must store complete ramsize in gd-ram_size */
+   gd-ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
+   PHYS_SDRAM_1_SIZE);
+   return 0;
+}
+
+u32 get_board_rev(void)
+{
+   u32 rev = get_cpu_rev();
+   if (!gpio_get_value(IMX_GPIO_NR(1, 22)))
+   rev |= BOARD_REV_2_0  BOARD_VER_OFFSET;
+   return rev;
+}
+
+#define UART_PAD_CTRL  (PAD_CTL_HYS | PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_HIGH)
+
+static void setup_iomux_uart(void)
+{
+   static const iomux_v3_cfg_t uart_pads[] = {
+   MX51_PAD_UART1_RXD__UART1_RXD,
+   MX51_PAD_UART1_TXD__UART1_TXD,
+   NEW_PAD_CTRL(MX51_PAD_UART1_RTS__UART1_RTS, UART_PAD_CTRL),
+   NEW_PAD_CTRL(MX51_PAD_UART1_CTS__UART1_CTS, UART_PAD_CTRL),
+   };
+
+   imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
+}
+
+#ifdef CONFIG_FSL_ESDHC
+int board_mmc_getcd(struct mmc *mmc)
+{
+   struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
+   int ret;
+
+   imx_iomux_v3_setup_pad(NEW_PAD_CTRL(MX51_PAD_GPIO1_0__GPIO1_0,
+   NO_PAD_CTRL));
+   

[U-Boot] [RFC PATCH 2/3] net: fec_mxc: query mac address from environment

[Damien Riegel]

The TS-4800 doesn't have its MAC address fused, therefore the
fec_mxc driver can not currently fetch it.

This commit adds the capability to fetch the MAC address from
environment if not found in fuses.

Signed-off-by: Damien Riegel damien.rie...@savoirfairelinux.com
Cc: Stefano Babic sba...@denx.de
Cc: Joe Hershberger joe.hershber...@ni.com
---
 drivers/net/fec_mxc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 9225d37..a789ecc 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1040,6 +1040,10 @@ static int fec_probe(bd_t *bd, int dev_id, uint32_t 
base_addr,
if (!getenv(ethaddr))
eth_setenv_enetaddr(ethaddr, ethaddr);
}
+   else if (eth_getenv_enetaddr(ethaddr, ethaddr)) {
+   debug(got MAC%d address from env: %pM\n, dev_id, ethaddr);
+   memcpy(edev-enetaddr, ethaddr, 6);
+   }
return ret;
 err4:
fec_free_descs(fec);
-- 
1.9.1

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

[U-Boot] [PATCH 4/4] sunxi: Add a proper dts file for the ga10h a33 based tablet

[Hans de Goede]

Add and use a proper dts for the ga10h a33 based tablet, as
submitted upstream.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sun8i-a33-ga10h-v1.1.dts | 142 ++
 configs/ga10h_v1_1_defconfig  |   2 +-
 3 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/sun8i-a33-ga10h-v1.1.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 501fe77..7c9043f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -127,6 +127,7 @@ dtb-$(CONFIG_MACH_SUN8I_A23) += \
sun8i-a23-ippo-q8h-v1.2.dtb
 dtb-$(CONFIG_MACH_SUN8I_A33) += \
sun8i-a33-et-q8-v1.6.dtb \
+   sun8i-a33-ga10h-v1.1.dtb \
sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
diff --git a/arch/arm/dts/sun8i-a33-ga10h-v1.1.dts 
b/arch/arm/dts/sun8i-a33-ga10h-v1.1.dts
new file mode 100644
index 000..1aefc67
--- /dev/null
+++ b/arch/arm/dts/sun8i-a33-ga10h-v1.1.dts
@@ -0,0 +1,142 @@
+/*
+ * Copyright 2015 Hans de Goede hdego...@redhat.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include sun8i-a33.dtsi
+#include sunxi-common-regulators.dtsi
+
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+#include dt-bindings/pinctrl/sun4i-a10.h
+
+/ {
+   model = Allwinner GA10H Quad Core Tablet (v1.1);
+   compatible = allwinner,ga10h-v1.1, allwinner,sun8i-a33;
+
+   aliases {
+   serial0 = r_uart;
+   };
+
+   chosen {
+   stdout-path = serial0:115200n8;
+   };
+};
+
+ehci0 {
+   status = okay;
+};
+
+i2c0 {
+   pinctrl-names = default;
+   pinctrl-0 = i2c0_pins_a;
+   status = okay;
+};
+
+i2c1 {
+   pinctrl-names = default;
+   pinctrl-0 = i2c1_pins_a;
+   status = okay;
+};
+
+lradc {
+   vref-supply = reg_vcc3v0;
+   status = okay;
+
+   button@200 {
+   label = Volume Up;
+   linux,code = KEY_VOLUMEUP;
+   channel = 0;
+   voltage = 20;
+   };
+
+   button@400 {
+   label = Volume Down;
+   linux,code = KEY_VOLUMEDOWN;
+   channel = 0;
+   voltage = 40;
+   };
+
+   button@600 {
+   label = Back;
+   linux,code = KEY_BACK;
+   channel = 0;
+   voltage = 60;
+   };
+};
+
+mmc0 {
+   pinctrl-names = default;
+   pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_q8h;
+   vmmc-supply = reg_vcc3v0;
+   bus-width = 4;
+   cd-gpios = pio 1 4 GPIO_ACTIVE_HIGH; /* PB4 */
+   cd-inverted;
+   status = okay;
+};
+
+ohci0 {
+   status = okay;
+};
+
+pio {
+   mmc0_cd_pin_q8h: mmc0_cd_pin@0 {
+   allwinner,pins = PB4;
+   allwinner,function = gpio_in;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+   };
+};
+
+r_uart {
+   pinctrl-names = 

[U-Boot] [PATCH 3/4] sunxi: Rename Astar_MID756 to Et_q8_v1_6 to match kernel dts name

[Hans de Goede]

Rename the Astar_MID756 to Et_q8_v1_6 to match the kernel dts name.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 board/sunxi/MAINTAINERS  | 10 +-
 configs/{Astar_MID756_defconfig = Et_q8_v1_6_defconfig} |  0
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename configs/{Astar_MID756_defconfig = Et_q8_v1_6_defconfig} (100%)

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 0618ec8..7a42055 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -64,11 +64,6 @@ M:   Paul Kocialkowski cont...@paulk.fr
 S: Maintained
 F: configs/Ampe_A76_defconfig
 
-Astar MID756 BOARD
-M: VishnuPatekar vishnupatekar0...@gmail.com
-S: Maintained
-F: configs/Astar_MID756_defconfig
-
 COLOMBUS BOARD
 M: Maxime Ripard maxime.rip...@free-electrons.com
 S: Maintained
@@ -82,6 +77,11 @@ F:   include/configs/sun7i.h
 F: configs/Cubieboard2_defconfig
 F: configs/Cubietruck_defconfig
 
+ET Q8 V1.6 Tablet BOARD
+M: VishnuPatekar vishnupatekar0...@gmail.com
+S: Maintained
+F: configs/Et_q8_v1_6_defconfig
+
 FORFUN-Q88DB TABLET
 M: Jens Lucius i...@jenslucius.com
 S: Maintained
diff --git a/configs/Astar_MID756_defconfig b/configs/Et_q8_v1_6_defconfig
similarity index 100%
rename from configs/Astar_MID756_defconfig
rename to configs/Et_q8_v1_6_defconfig
-- 
2.3.6

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

[U-Boot] [PATCH 1/4] sunxi: gpio: Add allwinner, sun8i-a33-pinctrl

[Hans de Goede]

Add allwinner,sun8i-a33-pinctrl, this is used by the latest upstream
linux sunxi dts files.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 drivers/gpio/sunxi_gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index f988130..afa165a 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -304,6 +304,7 @@ static const struct udevice_id sunxi_gpio_ids[] = {
{ .compatible = allwinner,sun6i-a31s-pinctrl },
{ .compatible = allwinner,sun7i-a20-pinctrl },
{ .compatible = allwinner,sun8i-a23-pinctrl },
+   { .compatible = allwinner,sun8i-a33-pinctrl },
{ .compatible = allwinner,sun9i-a80-pinctrl },
{ }
 };
-- 
2.3.6

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

[U-Boot] patch: fix typo in mxc_hab docs

[Chris Kuethe]

diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
index a1b1d34..5fe977c 100644
--- a/doc/README.mxc_hab
+++ b/doc/README.mxc_hab
@@ -69,7 +69,7 @@ CONFIG_SECURE_BOOT
 CONFIG_SYS_FSL_SEC_COMPAT4 /* HAB version */
 CONFIG_FSL_CAAM
 CONFIG_CMD_DEKBLOB
-CONFIG_SYS_FSL_LE
+CONFIG_SYS_FSL_SEC_LE

 Note: The encrypted boot feature is only supported by HABv4 or
 greater.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] sunxi: Sync dts files with the linux kernel

[Hans de Goede]

Copy over all the latest dts changes from mripard/sunxi/dt-for-4.2 ,
this gives us a proper dtsi file for the A33 rather then abusing
sun8i-a23.dtsi for this.

And this replaces our minimal (dummy) sun7i-a20-mk808c and
sun8i-a33-astar-mid756 dts files with proper ones.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/sun4i-a10-a1000.dts   |  11 +-
 arch/arm/dts/sun4i-a10-ba10-tvbox.dts  |  11 +-
 arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts |   5 -
 arch/arm/dts/sun4i-a10-cubieboard.dts  |  14 +-
 arch/arm/dts/sun4i-a10-gemei-g9.dts|   5 -
 arch/arm/dts/sun4i-a10-hackberry.dts   |  11 +-
 arch/arm/dts/sun4i-a10-hyundai-a7hd.dts|   5 -
 arch/arm/dts/sun4i-a10-inet97fv2.dts   |   5 -
 arch/arm/dts/sun4i-a10-jesurun-q5.dts  |  11 +-
 arch/arm/dts/sun4i-a10-marsboard.dts   |  12 +-
 arch/arm/dts/sun4i-a10-mini-xplus.dts  |   9 +-
 arch/arm/dts/sun4i-a10-mk802.dts   |   5 -
 arch/arm/dts/sun4i-a10-mk802ii.dts |   5 -
 arch/arm/dts/sun4i-a10-olinuxino-lime.dts  |   9 +-
 arch/arm/dts/sun4i-a10-pcduino.dts |   9 +-
 arch/arm/dts/sun4i-a10.dtsi| 146 --
 arch/arm/dts/sun5i-a10s-auxtek-t004.dts|   5 -
 arch/arm/dts/sun5i-a10s-mk802.dts  |   5 -
 arch/arm/dts/sun5i-a10s-olinuxino-micro.dts|   9 +-
 arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts   |   5 -
 arch/arm/dts/sun5i-a10s.dtsi   |  43 +-
 arch/arm/dts/sun5i-a13-hsg-h702.dts|   5 -
 arch/arm/dts/sun5i-a13-olinuxino-micro.dts |   5 -
 arch/arm/dts/sun5i-a13-olinuxino.dts   |   5 -
 arch/arm/dts/sun5i-a13-utoo-p66.dts|  27 +-
 arch/arm/dts/sun5i-a13.dtsi|  36 +-
 arch/arm/dts/sun5i.dtsi|  74 ++-
 arch/arm/dts/sun6i-a31-app4-evb1.dts   |   5 -
 arch/arm/dts/sun6i-a31-colombus.dts|   5 -
 arch/arm/dts/sun6i-a31-hummingbird.dts |   5 -
 arch/arm/dts/sun6i-a31-i7.dts  |   5 -
 arch/arm/dts/sun6i-a31-m9.dts  |   5 -
 arch/arm/dts/sun6i-a31.dtsi|  57 +-
 arch/arm/dts/sun6i-a31s-cs908.dts  |   5 -
 arch/arm/dts/sun6i-a31s.dtsi   |   5 -
 arch/arm/dts/sun7i-a20-bananapi.dts|  11 +-
 arch/arm/dts/sun7i-a20-bananapro.dts   |  17 +-
 arch/arm/dts/sun7i-a20-cubieboard2.dts |   7 +-
 arch/arm/dts/sun7i-a20-cubietruck.dts  |   7 +-
 arch/arm/dts/sun7i-a20-hummingbird.dts |  10 +-
 arch/arm/dts/sun7i-a20-i12-tvbox.dts   |   7 +-
 arch/arm/dts/sun7i-a20-m3.dts  |   7 +-
 arch/arm/dts/sun7i-a20-mk808c.dts  | 111 +++-
 arch/arm/dts/sun7i-a20-olinuxino-lime.dts  |   5 -
 arch/arm/dts/sun7i-a20-olinuxino-lime2.dts |   5 -
 arch/arm/dts/sun7i-a20-olinuxino-micro.dts |  11 +-
 arch/arm/dts/sun7i-a20-orangepi-mini.dts   |   7 +-
 arch/arm/dts/sun7i-a20-orangepi.dts|   7 +-
 arch/arm/dts/sun7i-a20-pcduino3-nano.dts   |   7 +-
 arch/arm/dts/sun7i-a20-pcduino3.dts|   7 +-
 arch/arm/dts/sun7i-a20-wexler-tab7200.dts  |   5 -
 arch/arm/dts/sun7i-a20.dtsi| 210 +---
 .../arm/dts/{sun8i-a23.dtsi = sun8i-a23-a33.dtsi} |  35 +-
 ...sun8i-a23-ippo-q8h-v5.dts = sun8i-a23-evb.dts} |  46 +-
 arch/arm/dts/sun8i-a23-ippo-q8h-v1.2.dts   |   5 -
 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts |   5 -
 arch/arm/dts/sun8i-a23.dtsi| 579 +
 arch/arm/dts/sun8i-a33-astar-mid756.dts|  29 --
 ...-a31-app4-evb1.dts = sun8i-a33-et-q8-v1.6.dts} |  48 +-
 .../dts/sun8i-a33-ippo-q8h-v1.2-lcd1024x600.dts|   2 +-
 ...{sun8i-a23-ippo-q8h-v1.2.dts = sun8i-a33.dtsi} |  60 ++-
 arch/arm/dts/sun9i-a80-optimus.dts |   5 -
 arch/arm/dts/sun9i-a80.dtsi|  13 +-
 arch/arm/dts/sunxi-common-regulators.dtsi  |   5 -
 configs/Astar_MID756_defconfig |   2 +-
 66 files changed, 672 insertions(+), 1190 deletions(-)
 copy arch/arm/dts/{sun8i-a23.dtsi = sun8i-a23-a33.dtsi} (95%)
 copy arch/arm/dts/{sun8i-a23-ippo-q8h-v5.dts = sun8i-a23-evb.dts} (81%)
 delete mode 100644 arch/arm/dts/sun8i-a33-astar-mid756.dts
 copy arch/arm/dts/{sun6i-a31-app4-evb1.dts = sun8i-a33-et-q8-v1.6.dts} (73%)
 copy arch/arm/dts/{sun8i-a23-ippo-q8h-v1.2.dts = sun8i-a33.dtsi} (68%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index acbd9b4..501fe77 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -122,10 +122,11 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-wits-pro-a20-dkt.dtb \
 

[U-Boot] [RFC PATCH 0/3] ARM: ts4800: add board support

[Damien Riegel]

This patchset adds support for TS4800, a Technologic Systems' board.
This board is a bit peculiar because most of the init is done by the
FPGA and U-Boot is used as a second stage bootloader.

Ethernet support is added in a separate commit because it requires
a modification of the fec_mxc driver. On this board, MAC address is
not fused, so the driver needs another way to get it.

Files have been put in board/technologic/ to follow the same convention
as Technologic Systems [1].

[1] https://github.com/embeddedarm/u-boot

Cc: Stefano Babic sba...@denx.de

Damien Riegel (2):
  net: fec_mxc: query mac address from environment
  ARM: ts4800: add ethernet support

Lucile Quirion (1):
  ARM: ts4800: add basic board support

 arch/arm/Kconfig   |   5 +
 arch/arm/include/asm/arch-mx5/iomux-mx51.h |  11 ++
 board/technologic/ts4800/Kconfig   |  15 ++
 board/technologic/ts4800/MAINTAINERS   |   6 +
 board/technologic/ts4800/Makefile  |   7 +
 board/technologic/ts4800/ts4800.c  | 259 +
 configs/ts4800_defconfig   |   2 +
 drivers/net/fec_mxc.c  |   4 +
 include/configs/ts4800.h   | 187 +
 9 files changed, 496 insertions(+)
 create mode 100644 board/technologic/ts4800/Kconfig
 create mode 100644 board/technologic/ts4800/MAINTAINERS
 create mode 100644 board/technologic/ts4800/Makefile
 create mode 100644 board/technologic/ts4800/ts4800.c
 create mode 100644 configs/ts4800_defconfig
 create mode 100644 include/configs/ts4800.h

-- 
1.9.1

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

[U-Boot] [RFC PATCH 3/3] ARM: ts4800: add ethernet support

[Damien Riegel]

This commit adds ethernet support to the TS4800. Note that the
MAC address is not fused on this board and have to be read from
FEC PALR PAUR registers (this is how the kernel provided by
Technologic Systems does it).

Signed-off-by: Damien Riegel damien.rie...@savoirfairelinux.com
Cc: Stefano Babic sba...@denx.de
---
 arch/arm/include/asm/arch-mx5/iomux-mx51.h |  11 +++
 board/technologic/ts4800/ts4800.c  | 104 +
 include/configs/ts4800.h   |  17 +
 3 files changed, 132 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx5/iomux-mx51.h 
b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
index 70aaa37..0056d73 100644
--- a/arch/arm/include/asm/arch-mx5/iomux-mx51.h
+++ b/arch/arm/include/asm/arch-mx5/iomux-mx51.h
@@ -184,8 +184,15 @@ enum {
MX51_PAD_DISPB2_SER_DIO__GPIO3_6= IOMUX_PAD(0x6c0, 0x2c0, 4, 
0x98c, 1, MX51_GPIO_PAD_CTRL),
MX51_PAD_DI1_PIN3__DI1_PIN3 = IOMUX_PAD(0x72c, 0x32c, 0, 
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_DI1_PIN2__DI1_PIN2 = IOMUX_PAD(0x734, 0x330, 0, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_DI2_PIN2__FEC_MDC  = IOMUX_PAD(0x74C, 0x344, 2, 
__NA_, 0, MX51_PAD_CTRL_5),
MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK = IOMUX_PAD(0x754, 0x34c, 0, 
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_DI_GP4__DI2_PIN15  = IOMUX_PAD(0x758, 0x350, 4, 
__NA_, 0, NO_PAD_CTRL),
+   MX51_PAD_DISP2_DAT6__FEC_TDAT1  = IOMUX_PAD(0x774, 0x36C, 2, 
__NA_, 0, MX51_PAD_CTRL_5),
+   MX51_PAD_DISP2_DAT7__FEC_TDAT2  = IOMUX_PAD(0x778, 0x370, 2, 
__NA_, 0, MX51_PAD_CTRL_5),
+   MX51_PAD_DISP2_DAT8__FEC_TDAT3  = IOMUX_PAD(0x77C, 0x374, 2, 
__NA_, 0, MX51_PAD_CTRL_5),
+   MX51_PAD_DISP2_DAT9__FEC_TX_EN  = IOMUX_PAD(0x780, 0x378, 2, 
__NA_, 0, MX51_PAD_CTRL_5),
+   MX51_PAD_DISP2_DAT12__FEC_RX_DV = IOMUX_PAD(0x78C, 0x384, 2, 
0x96c, 0x1, MX51_PAD_CTRL_4),
+   MX51_PAD_DISP2_DAT13__FEC_TX_CLK= IOMUX_PAD(0x790, 0x388, 2, 
0x974, 0x1, MX51_PAD_CTRL_4),
MX51_PAD_SD1_CMD__SD1_CMD   = IOMUX_PAD(0x79c, 0x394, 0x10, 
__NA_, 0, MX51_SDHCI_PAD_CTRL),
MX51_PAD_SD1_CLK__SD1_CLK   = IOMUX_PAD(0x7a0, 0x398, 0x10, 
__NA_, 0, MX51_SDHCI_PAD_CTRL | PAD_CTL_HYS),
MX51_PAD_SD1_DATA0__SD1_DATA0   = IOMUX_PAD(0x7a4, 0x39c, 0x10, 
__NA_, 0, MX51_SDHCI_PAD_CTRL),
@@ -204,6 +211,10 @@ enum {
MX51_PAD_GPIO1_2__GPIO1_2   = IOMUX_PAD(0x7d4, 0x3cc, 0, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_GPIO1_2__PWM1_PWMO = IOMUX_PAD(0x7d4, 0x3cc, 1, 
__NA_, 0, NO_PAD_CTRL),
MX51_PAD_GPIO1_3__GPIO1_3   = IOMUX_PAD(0x7d8, 0x3d0, 0, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
+   MX51_PAD_DISP2_DAT10__FEC_COL   = IOMUX_PAD(0x784, 0x37C, 2, 
0x94c, 0x1, MX51_PAD_CTRL_2),
+   MX51_PAD_DISP2_DAT11__FEC_RXCLK = IOMUX_PAD(0x788, 0x380, 2, 
0x968, 0x1, MX51_PAD_CTRL_2),
+   MX51_PAD_DISP2_DAT14__FEC_RDAT0 = IOMUX_PAD(0x794, 0x38C, 2, 
0x958, 0x1, MX51_PAD_CTRL_4),
+   MX51_PAD_DISP2_DAT15__FEC_TDAT0 = IOMUX_PAD(0x798, 0x390, 2, 
0x0, 0, MX51_PAD_CTRL_5),
MX51_PAD_GPIO1_5__GPIO1_5   = IOMUX_PAD(0x808, 0x3dc, 0, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_GPIO1_6__GPIO1_6   = IOMUX_PAD(0x80c, 0x3e0, 0, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
MX51_PAD_GPIO1_7__GPIO1_7   = IOMUX_PAD(0x810, 0x3e4, 0, 
__NA_, 0, MX51_GPIO_PAD_CTRL),
diff --git a/board/technologic/ts4800/ts4800.c 
b/board/technologic/ts4800/ts4800.c
index e49f185..6b762b2 100644
--- a/board/technologic/ts4800/ts4800.c
+++ b/board/technologic/ts4800/ts4800.c
@@ -21,6 +21,10 @@
 #include fsl_esdhc.h
 #include mc13892.h
 
+#include malloc.h
+#include netdev.h
+#include phy.h
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #ifdef CONFIG_FSL_ESDHC
@@ -60,6 +64,36 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
 }
 
+static void setup_iomux_fec(void)
+{
+   static const iomux_v3_cfg_t fec_pads[] = {
+   NEW_PAD_CTRL(MX51_PAD_EIM_EB2__FEC_MDIO,
+   PAD_CTL_HYS |
+   PAD_CTL_PUS_22K_UP |
+   PAD_CTL_DSE_HIGH | PAD_CTL_SRE_FAST),
+   MX51_PAD_EIM_EB3__FEC_RDATA1,
+   NEW_PAD_CTRL(MX51_PAD_EIM_CS2__FEC_RDATA2, PAD_CTL_HYS),
+   MX51_PAD_EIM_CS3__FEC_RDATA3,
+   MX51_PAD_NANDF_CS2__FEC_TX_ER,
+   MX51_PAD_EIM_CS5__FEC_CRS,
+   MX51_PAD_EIM_CS4__FEC_RX_ER,
+   /* PAD used on TS4800 */
+   MX51_PAD_DI2_PIN2__FEC_MDC,
+   MX51_PAD_DISP2_DAT14__FEC_RDAT0,
+   MX51_PAD_DISP2_DAT10__FEC_COL,
+   MX51_PAD_DISP2_DAT11__FEC_RXCLK,
+   MX51_PAD_DISP2_DAT15__FEC_TDAT0,
+   MX51_PAD_DISP2_DAT6__FEC_TDAT1,
+   

Re: [U-Boot] patch - arm - define SYS_CACHELINE_SIZE for mx5

[Fabio Estevam]

On Tue, Jun 2, 2015 at 8:31 PM, Chris Kuethe chris.kue...@gmail.com wrote:
 mx5 is a cortex-a8 which has 64 byte cache lines. i'll need this for
 adding gadget support to usbarmory, but it's a property common the the
 entire SoC family - may as well make it available to all MX5 boards

 Works on usbarmory; compile-tested on mx53loco and mx51_efikamx too

 Signed-off-by: Chris Kuethe chris.kue...@gmail.com
 Cc: Tom Rini tr...@konsulko.com
 Cc: Matthew Starr mst...@hedonline.com
 Cc: Andrej Rosano and...@inversepath.com
 Cc: Stefano Babic sba...@denx.de
 Cc: Chris Kuethe chris.kue...@gmail.com
 Cc: Fabio Estevam feste...@gmail.com
 Cc: Marek Vasut ma...@denx.de

 diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
 b/arch/arm/include/asm/arch-mx5/imx-regs.h
 index f059d0f..5f0e1e6 100644
 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h
 +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
 @@ -9,6 +9,8 @@

  #define ARCH_MXC

 +#define CONFIG_SYS_CACHELINE_SIZE 64
 +

This is correct for Cortex A8:

Reviewed-by: Fabio Estevam fabio.este...@freescale.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Issue about support spi-nand in u-boot

[peterpandong]

On 29 May 2015 at 19:53, Jagan Teki jt...@openedev.com wrote
 On 29 May 2015 at 11:42, Peter Pan 潘栋 (peterpandong)
 peterpand...@micron.com wrote:
  Hi Jagan
 
  I looked through your code[1] about support Linux spi-nor framework
 in u-boot.
  It is really great.
 
 I'm bit concern about the spi-flash framework and planning to make
 generic
 thanks for your response on this.
 
 
  I'm working on spi-nand in u-boot now. And I met some issues. Maybe
 we
  can have a discussion.
1. Currently spi_flash struct is tied with spi nor, as spi nand is
 also
   a kind of spi flash. I think we should make spi_flash struct
 shareable.
2. In Linux, we can use parameter .tx_nbits and .rx_nbits in
 spi_transfer
   struct to tell controller driver to use 1bit, 2bits or 4bits to
 transfer
   data. But I didn't find a way to do it in u-boot. Maybe we can
 add some
   transfer flags to do this.
 
 We handle these on flash code it self, by assigning SINGLE, DUAL and
 QUAD commands
 from the controller flags. See tha drivers/mtd/spi/sf-probe.c if you
 still unclear let me know
 will discuss more.

You mean that currently spi nor code assign SINGLE, DUAL or QUAD command
to spi nor specified controller, then controller decided how many pins
are used for data transfer by decode the command?

At present, I think there are few spi nand specified controller. I'm using
a generic spi controller. Now I handle all the things(including pin numbers)
in the spi nand code, spi controller just do data transfer(no difference
between command and data). That why I need a flag to do it.

Also, We can let spi controller driver to handle the things. Controller
driver treat the first byte of the transfer with SPI_XFER_BEGIN flag as
command. By decode the command do the right transfer.

Which method do you think is more appropriate? 

 
3. Should we use spi nand via sf command set or create another
 command set?
 
 
 question 1, 3 - Below are my understanding till now about the
 implementation, just grab
 these probably will discuss more.
 
 I'm also thinking that the spi-flash.h should be common to nor and
 nand and from flash
 code level there should be a generic code that intern divide the
 spi-nor and spi-nand.
 
 Let's say cmd_sf will take nor or nand ops from user and this will
 intern call flash code in
 drivers/mtd like drivers/mtd/spi/spi-nor-flash.c in my new code. So
 spi-nor-flash.c will become
 spi-flash.c this have capability to handle spi-nor and spi-nand. Each
 spi-nor and spi-nand have
 separate in-built cores(spi-nor.c and spi-nand.c).

I also prefer share cmd_sf. And If do so, maybe we need add a sf command
to do oob ops for nand, right?

 
 And then spi-nor.c will again transition to general spi drivers -
 drivers/spi/ and few flash specific
 spi drivers(not implemented yet) those will be drivers/mtd/spi/nor.
 For spi-nand.c will again transition
 to general nand drivers - drivers/mtd/nand/ and few flash specific
 nand drivers (if they) those will be
 drivers/mtd/spi/nand.
 
 common/cmd_sf.c -- handle both spi-nor/nand
 include/spi_flash.c -- handle spi-flash stuff both for spi-nor/nand
 
 drivers/mtd/spi/ -- for spi flash code
 
 drivers/mtd/spi/nor -- for spi-nor code
 drivers/mtd/spi/nor.c -- for spi-nor core
 drivers/mtd/spi/zynq_qspi.c -- zynq spi-nor controller (thought it's
 (q)spi controller, but particularly
  implemented for spi-nor based
 functionalists)
 include/spi-nor.h -- header file for spi-nor core
 
 drivers/mtd/spi/nand -- for spi-nand code
 drivers/mtd/spi/nand.c -- for spi-nand core
 drivers/mtd/spi/xxx_snand.c -- xxx spi-nand controller (thought it's
 nand controller, but particularly implemented for spi-nand based
 functionalists)
 include/spi-nand.h -- header file for spi-nand core
 

This is really a good structure. I'm a big fan of it.

  Any suggestion is appreciated.
 
  Another question, do you have any schedule about when to merge spi-
 nor framework?
 
 Probably in the coming release, once this is in few of the driver in
 drivers/spi need to write
 back to spi-nor layer (those are full flash specific)

I really appreciate your work. I would help you on it if you need.

 
 
  [1] http://git.denx.de/?p=u-boot/u-boot-
 spi.git;a=shortlog;h=refs/heads/spi-nor
 
 thanks!
 --
 Jagan Teki,
 Openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/5] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Bin Meng]

The following error is observed on QEMU x86.

= print ipaddr
ipaddr=192.168.178.66
= ping 192.168.178.1
*** ERROR: `ipaddr' not set
ping failed; host 192.168.178.1 is not alive

The issue was introduced in commit fd30563. Adding CMD_NET to
defconfig resolves this.

Signed-off-by: Bin Meng bmeng...@gmail.com

---

Changes in v2:
- New patch to fix the networking issue

 configs/qemu-x86_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 198ab97..4509d52 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -1,6 +1,7 @@
 CONFIG_X86=y
 CONFIG_VENDOR_EMULATION=y
 CONFIG_TARGET_QEMU_X86=y
+CONFIG_CMD_NET=y
 CONFIG_OF_CONTROL=y
 CONFIG_OF_SEPARATE=y
 CONFIG_DEFAULT_DEVICE_TREE=qemu-x86
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 1/5] x86: coreboot: Fix cosmetic issues

[Bin Meng]

Clean up arch/x86/cpu/coreboot.c to fix several cosmetic issues.

Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org

---

Changes in v2:
- Drop v1 patches already applied
- Add asm/io.h inclusion back

 arch/x86/cpu/coreboot/coreboot.c  | 27 +++
 arch/x86/include/asm/u-boot-x86.h |  1 -
 2 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 4cdd0d4..c3dfd28 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -7,16 +7,10 @@
  */
 
 #include common.h
-#include asm/u-boot-x86.h
-#include flash.h
 #include netdev.h
-#include ns16550.h
-#include asm/msr.h
-#include asm/cache.h
-#include asm/cpu.h
 #include asm/io.h
+#include asm/msr.h
 #include asm/mtrr.h
-#include asm/arch/tables.h
 #include asm/arch/sysinfo.h
 #include asm/arch/timestamp.h
 
@@ -53,13 +47,6 @@ int last_stage_init(void)
return 0;
 }
 
-#ifndef CONFIG_SYS_NO_FLASH
-ulong board_flash_get_legacy(ulong base, int banknum, flash_info_t *info)
-{
-   return 0;
-}
-#endif
-
 int board_eth_init(bd_t *bis)
 {
return pci_eth_init(bis);
@@ -67,7 +54,8 @@ int board_eth_init(bd_t *bis)
 
 void board_final_cleanup(void)
 {
-   /* Un-cache the ROM so the kernel has one
+   /*
+* Un-cache the ROM so the kernel has one
 * more MTRR available.
 *
 * Coreboot should have assigned this to the
@@ -91,15 +79,6 @@ void board_final_cleanup(void)
outb(0xcb, 0xb2);
 }
 
-void panic_puts(const char *str)
-{
-   NS16550_t port = (NS16550_t)0x3f8;
-
-   NS16550_init(port, 1);
-   while (*str)
-   NS16550_putc(port, *str++);
-}
-
 int misc_init_r(void)
 {
return 0;
diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index be103c0..d1d21ed 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -16,7 +16,6 @@ void init_gd(gd_t *id, u64 *gdt_addr);
 void setup_gdt(gd_t *id, u64 *gdt_addr);
 int init_cache(void);
 int cleanup_before_linux(void);
-void panic_puts(const char *str);
 
 /* cpu/.../timer.c */
 void timer_isr(void *);
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 3/5] x86: qemu: Create separate i440fx and q35 device trees

[Bin Meng]

Although the two qemu-x86 targets (i440fx and q35) share a lot in
common, they still have something that cannot easily handled in one
single device tree). Split to create two dedicated device tree files
and make the i440fx be the default build target.

Signed-off-by: Bin Meng bmeng...@gmail.com

---

Changes in v2:
- Still use one board configuration file qemu-x86.h

 arch/x86/dts/Makefile   |  3 ++-
 arch/x86/dts/qemu-x86_i440fx.dts| 34 +
 arch/x86/dts/{qemu-x86.dts = qemu-x86_q35.dts} |  2 +-
 board/coreboot/coreboot/Kconfig |  2 +-
 configs/qemu-x86_defconfig  |  3 +--
 doc/README.x86  | 10 +++-
 6 files changed, 48 insertions(+), 6 deletions(-)
 create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
 rename arch/x86/dts/{qemu-x86.dts = qemu-x86_q35.dts} (95%)

diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index ca2eab3..f86514c 100644
--- a/arch/x86/dts/Makefile
+++ b/arch/x86/dts/Makefile
@@ -3,7 +3,8 @@ dtb-y += chromebook_link.dtb \
crownbay.dtb \
galileo.dtb \
minnowmax.dtb \
-   qemu-x86.dtb
+   qemu-x86_i440fx.dtb \
+   qemu-x86_q35.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/x86/dts/qemu-x86_i440fx.dts b/arch/x86/dts/qemu-x86_i440fx.dts
new file mode 100644
index 000..4cf843b
--- /dev/null
+++ b/arch/x86/dts/qemu-x86_i440fx.dts
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2015, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+
+/include/ skeleton.dtsi
+/include/ serial.dtsi
+
+/ {
+   model = QEMU x86 (I440FX);
+   compatible = qemu,x86;
+
+   config {
+   silent_console = 0;
+   };
+
+   chosen {
+   stdout-path = /serial;
+   };
+
+   pci {
+   compatible = pci-x86;
+   #address-cells = 3;
+   #size-cells = 2;
+   u-boot,dm-pre-reloc;
+   ranges = 0x0200 0x0 0xc000 0xc000 0 0x1000
+   0x4200 0x0 0xd000 0xd000 0 0x1000
+   0x0100 0x0 0x2000 0x2000 0 0xe000;
+   };
+
+};
diff --git a/arch/x86/dts/qemu-x86.dts b/arch/x86/dts/qemu-x86_q35.dts
similarity index 95%
rename from arch/x86/dts/qemu-x86.dts
rename to arch/x86/dts/qemu-x86_q35.dts
index f1291b5..6c89283 100644
--- a/arch/x86/dts/qemu-x86.dts
+++ b/arch/x86/dts/qemu-x86_q35.dts
@@ -10,7 +10,7 @@
 /include/ serial.dtsi
 
 / {
-   model = QEMU x86;
+   model = QEMU x86 (Q35);
compatible = qemu,x86;
 
config {
diff --git a/board/coreboot/coreboot/Kconfig b/board/coreboot/coreboot/Kconfig
index 69e3437..3ff64f4 100644
--- a/board/coreboot/coreboot/Kconfig
+++ b/board/coreboot/coreboot/Kconfig
@@ -23,7 +23,7 @@ config SYS_CONFIG_NAME
 
 config DEFAULT_DEVICE_TREE
string Board Device Tree Source (dts) file
-   default qemu-x86
+   default qemu-x86_i440fx
help
  This option selects the board Device Tree Source (dts) file in
  arch/x86/dts/ directory to be used to build U-Boot for coreboot.
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 4509d52..0959a98 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -1,10 +1,9 @@
 CONFIG_X86=y
 CONFIG_VENDOR_EMULATION=y
+CONFIG_DEFAULT_DEVICE_TREE=qemu-x86_i440fx
 CONFIG_TARGET_QEMU_X86=y
 CONFIG_CMD_NET=y
 CONFIG_OF_CONTROL=y
-CONFIG_OF_SEPARATE=y
-CONFIG_DEFAULT_DEVICE_TREE=qemu-x86
 CONFIG_VIDEO_VESA=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_111=y
diff --git a/doc/README.x86 b/doc/README.x86
index 0726205..c19f4a0 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -40,7 +40,7 @@ configuration during the 'make menuconfig' process.
 x86 architecture  ---
...
(qemu-x86) Board configuration file
-   (qemu-x86) Board Device Tree Source (dts) file
+   (qemu-x86_i440fx) Board Device Tree Source (dts) file
(0x0192) Board specific Cache-As-RAM (CAR) address
(0x4000) Board specific Cache-As-RAM (CAR) size
 
@@ -186,6 +186,14 @@ To build u-boot.rom for QEMU x86 targets, just simply run
 $ make qemu-x86_defconfig
 $ make all
 
+Note this default configuration will build a U-Boot for the QEMU x86 i440FX
+board. To build a U-Boot against QEMU x86 Q35 board, you can change the build
+configuration during the 'make menuconfig' process like below:
+
+Device Tree Control  ---
+   ...
+   (qemu-x86_q35) Default Device Tree for DT control
+
 Test with coreboot
 --
 For testing U-Boot as the coreboot payload, there are things that need be paid
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 5/5] x86: qemu: Implement PIRQ routing

[Bin Meng]

Support QEMU PIRQ routing via device tree on both i440fx and q35
platforms. With this commit, Linux booting on QEMU from U-Boot
has working ATA/SATA, USB and ethernet.

Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
---

Changes in v2: None

 arch/x86/cpu/coreboot/coreboot.c |  5 +
 arch/x86/cpu/qemu/qemu.c |  8 
 arch/x86/dts/qemu-x86_i440fx.dts | 16 
 arch/x86/dts/qemu-x86_q35.dts| 32 
 configs/qemu-x86_defconfig   |  1 +
 include/configs/qemu-x86.h   |  1 +
 6 files changed, 63 insertions(+)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index c4cac04..0e9f15f 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -89,3 +89,8 @@ int misc_init_r(void)
 {
return 0;
 }
+
+int arch_misc_init(void)
+{
+   return 0;
+}
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 0f98476..930d2b6 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -5,6 +5,7 @@
  */
 
 #include common.h
+#include asm/irq.h
 #include asm/post.h
 #include asm/processor.h
 
@@ -35,3 +36,10 @@ void reset_cpu(ulong addr)
/* cold reset */
x86_full_reset();
 }
+
+int arch_misc_init(void)
+{
+   pirq_init();
+
+   return 0;
+}
diff --git a/arch/x86/dts/qemu-x86_i440fx.dts b/arch/x86/dts/qemu-x86_i440fx.dts
index 4cf843b..557428a 100644
--- a/arch/x86/dts/qemu-x86_i440fx.dts
+++ b/arch/x86/dts/qemu-x86_i440fx.dts
@@ -6,6 +6,8 @@
 
 /dts-v1/;
 
+#include dt-bindings/interrupt-router/intel-irq.h
+
 /include/ skeleton.dtsi
 /include/ serial.dtsi
 
@@ -29,6 +31,20 @@
ranges = 0x0200 0x0 0xc000 0xc000 0 0x1000
0x4200 0x0 0xd000 0xd000 0 0x1000
0x0100 0x0 0x2000 0x2000 0 0xe000;
+
+   irq-router@1,0 {
+   reg = 0x0800 0 0 0 0;
+   compatible = intel,irq-router;
+   intel,pirq-config = pci;
+   intel,pirq-link = 0x60 4;
+   intel,pirq-mask = 0x0e40;
+   intel,pirq-routing = 
+   /* PIIX UHCI */
+   PCI_BDF(0, 1, 2) INTD PIRQD
+   /* e1000 NIC */
+   PCI_BDF(0, 3, 0) INTA PIRQC
+   ;
+   };
};
 
 };
diff --git a/arch/x86/dts/qemu-x86_q35.dts b/arch/x86/dts/qemu-x86_q35.dts
index 02a483c..c259f2a 100644
--- a/arch/x86/dts/qemu-x86_q35.dts
+++ b/arch/x86/dts/qemu-x86_q35.dts
@@ -6,6 +6,18 @@
 
 /dts-v1/;
 
+#include dt-bindings/interrupt-router/intel-irq.h
+
+/* ICH9 IRQ router has discrete PIRQ control registers */
+#undef PIRQE
+#undef PIRQF
+#undef PIRQG
+#undef PIRQH
+#define PIRQE  8
+#define PIRQF  9
+#define PIRQG  10
+#define PIRQH  11
+
 /include/ skeleton.dtsi
 /include/ serial.dtsi
 
@@ -30,6 +42,26 @@
ranges = 0x0200 0x0 0xc000 0xc000 0 0x1000
0x4200 0x0 0xd000 0xd000 0 0x1000
0x0100 0x0 0x2000 0x2000 0 0xe000;
+
+   irq-router@1f,0 {
+   reg = 0xf800 0 0 0 0;
+   compatible = intel,irq-router;
+   intel,pirq-config = pci;
+   intel,pirq-link = 0x60 8;
+   intel,pirq-mask = 0x0e40;
+   intel,pirq-routing = 
+   /* e1000 NIC */
+   PCI_BDF(0, 2, 0) INTA PIRQG
+   /* ICH9 UHCI */
+   PCI_BDF(0, 29, 0) INTA PIRQA
+   PCI_BDF(0, 29, 1) INTB PIRQB
+   PCI_BDF(0, 29, 2) INTC PIRQC
+   /* ICH9 EHCI */
+   PCI_BDF(0, 29, 7) INTD PIRQD
+   /* ICH9 SATA */
+   PCI_BDF(0, 31, 2) INTA PIRQA
+   ;
+   };
};
 
 };
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 0959a98..901cbd7 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -2,6 +2,7 @@ CONFIG_X86=y
 CONFIG_VENDOR_EMULATION=y
 CONFIG_DEFAULT_DEVICE_TREE=qemu-x86_i440fx
 CONFIG_TARGET_QEMU_X86=y
+CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_CMD_NET=y
 CONFIG_OF_CONTROL=y
 CONFIG_VIDEO_VESA=y
diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h
index d01936b..78c296f 100644
--- a/include/configs/qemu-x86.h
+++ b/include/configs/qemu-x86.h
@@ -14,6 +14,7 @@
 #include configs/x86-common.h
 
 #define CONFIG_SYS_MONITOR_LEN (1  20)
+#define CONFIG_ARCH_MISC_INIT
 
 #define CONFIG_X86_SERIAL
 
-- 
1.8.2.1

___
U-Boot 

[U-Boot] [PATCH v2 4/5] x86: coreboot: Control I/O port 0xb2 writing via device tree

[Bin Meng]

Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
U-Boot to hang on QEMU q35 target. We introduce a config option in the
device tree u-boot,no-apm-finalize under /config node if we don't want
to do that.

Signed-off-by: Bin Meng bmeng...@gmail.com

---

Changes in v2:
- Use a config option in the device tree instead of deleting the codes

 arch/x86/cpu/coreboot/coreboot.c | 12 +---
 arch/x86/dts/qemu-x86_q35.dts|  1 +
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index c3dfd28..c4cac04 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -7,6 +7,7 @@
  */
 
 #include common.h
+#include fdtdec.h
 #include netdev.h
 #include asm/io.h
 #include asm/msr.h
@@ -74,9 +75,14 @@ void board_final_cleanup(void)
mtrr_close(state);
}
 
-   /* Issue SMI to Coreboot to lock down ME and registers */
-   printf(Finalizing Coreboot\n);
-   outb(0xcb, 0xb2);
+   if (!fdtdec_get_config_bool(gd-fdt_blob, u-boot,no-apm-finalize)) {
+   /*
+* Issue SMI to coreboot to lock down ME and registers
+* when allowed via device tree
+*/
+   printf(Finalizing coreboot\n);
+   outb(0xcb, 0xb2);
+   }
 }
 
 int misc_init_r(void)
diff --git a/arch/x86/dts/qemu-x86_q35.dts b/arch/x86/dts/qemu-x86_q35.dts
index 6c89283..02a483c 100644
--- a/arch/x86/dts/qemu-x86_q35.dts
+++ b/arch/x86/dts/qemu-x86_q35.dts
@@ -15,6 +15,7 @@
 
config {
silent_console = 0;
+   u-boot,no-apm-finalize;
};
 
chosen {
-- 
1.8.2.1

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

Re: [U-Boot] [RFC PATCH 2/2] x86: fsp: Move FspInitEntry call to board_init_f()

[Bin Meng]

Hi Andrew,

On Wed, Jun 3, 2015 at 4:05 AM, Andrew Bradford
and...@bradfordembedded.com wrote:
 Hi Bin,

 On 06/01 20:31, Bin Meng wrote:
 The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
 It worked pretty well but looks not that good. Apart from doing too
 much work than just enabling CAR, it cannot read the configuration
 data from device tree at that time. Now we want to move it a little
 bit later as part of init_sequence_f[] being called by board_init_f().
 This way it looks and works better in the U-Boot initialization path.

 Due to FSP's design, after calling FspInitEntry it will not return to
 its caller, instead it jumps to a continuation function which is given
 by bootloader with a new stack in system memory. The original stack in
 the CAR is gone, but its content is perserved by FSP and described by
 a bootloader temporary memory HOB. Technically we can recover anything
 we had before in the previous stack, but that is way too complicated.
 To make life much easier, in the FSP continuation routine we just
 simply call fsp_init_done() and jump back to car_init_ret() to redo
 the whole board_init_f() initialization, but this time with a non-zero
 HOB list pointer saved in U-Boot's global data so that we can bypass
 the FspInitEntry for the second time.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

  arch/x86/cpu/start.S  |  6 +-
  arch/x86/include/asm/u-boot-x86.h |  4 
  arch/x86/lib/fsp/fsp_car.S| 26 +-
  arch/x86/lib/fsp/fsp_common.c |  8 
  common/board_f.c  |  3 +++
  5 files changed, 25 insertions(+), 22 deletions(-)

 diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
 index 2e5f9da..00e585e 100644
 --- a/arch/x86/cpu/start.S
 +++ b/arch/x86/cpu/start.S
 @@ -116,12 +116,16 @@ car_init_ret:
   rep stosb

  #ifdef CONFIG_HAVE_FSP
 + test%esi, %esi
 + jz  skip_hob
 +
   /* Store HOB list */
   movl%esp, %edx
   addl$GD_HOB_LIST, %edx
   movl%esi, (%edx)
 -#endif

 +skip_hob:
 +#endif
   /* Setup first parameter to setup_gdt, pointer to global_data */
   movl%esp, %eax

 diff --git a/arch/x86/include/asm/u-boot-x86.h 
 b/arch/x86/include/asm/u-boot-x86.h
 index faa5182..9ee4104 100644
 --- a/arch/x86/include/asm/u-boot-x86.h
 +++ b/arch/x86/include/asm/u-boot-x86.h
 @@ -54,6 +54,10 @@ u32 isa_map_rom(u32 bus_addr, int size);
  /* arch/x86/lib/... */
  int video_bios_init(void);

 +#ifdef CONFIG_HAVE_FSP
 +int x86_fsp_init(void);
 +#endif
 +
  void board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
  void board_init_f_r(void) __attribute__ ((noreturn));

 diff --git a/arch/x86/lib/fsp/fsp_car.S b/arch/x86/lib/fsp/fsp_car.S
 index 5e09568..afbf3f9 100644
 --- a/arch/x86/lib/fsp/fsp_car.S
 +++ b/arch/x86/lib/fsp/fsp_car.S
 @@ -56,28 +56,10 @@ temp_ram_init_ret:

   /* stack grows down from top of CAR */
   movl%edx, %esp
 + subl$4, %esp

 - /*
 -  * TODO:
 -  *
 -  * According to FSP architecture spec, the fsp_init() will not return
 -  * to its caller, instead it requires the bootloader to provide a
 -  * so-called continuation function to pass into the FSP as a parameter
 -  * of fsp_init, and fsp_init() will call that continuation function
 -  * directly.
 -  *
 -  * The call to fsp_init() may need to be moved out of the car_init()
 -  * to cpu_init_f() with the help of some inline assembly codes.
 -  * Note there is another issue that fsp_init() will setup another stack
 -  * using the fsp_init parameter stack_top after DRAM is initialized,
 -  * which means any data on the previous stack (on the CAR) gets lost
 -  * (ie: U-Boot global_data). FSP is supposed to support such scenario,
 -  * however it does not work. This should be revisited in the future.
 -  */
 - movl$CONFIG_FSP_TEMP_RAM_ADDR, %eax
 - xorl%edx, %edx
 - xorl%ecx, %ecx
 - callfsp_init
 + xor %esi, %esi
 + jmp car_init_done

  .global fsp_init_done
  fsp_init_done:
 @@ -86,6 +68,8 @@ fsp_init_done:
* Save eax to esi temporarily.
*/
   movl%eax, %esi
 +
 +car_init_done:
   /*
* Re-initialize the ebp (BIST) to zero, as we already reach here
* which means we passed BIST testing before.
 diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
 index 001494d..5b25632 100644
 --- a/arch/x86/lib/fsp/fsp_common.c
 +++ b/arch/x86/lib/fsp/fsp_common.c
 @@ -46,3 +46,11 @@ void board_final_cleanup(void)

   return;
  }
 +
 +int x86_fsp_init(void)
 +{
 + if (!gd-arch.hob_list)
 + fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, NULL);
 +
 + return 0;
 +}
 diff --git a/common/board_f.c b/common/board_f.c
 index fbbad1b..21be26f 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -753,6 +753,9 @@ static init_fnc_t 

[U-Boot] patch - arm - define SYS_CACHELINE_SIZE for mx5

[Chris Kuethe]

mx5 is a cortex-a8 which has 64 byte cache lines. i'll need this for
adding gadget support to usbarmory, but it's a property common the the
entire SoC family - may as well make it available to all MX5 boards

Works on usbarmory; compile-tested on mx53loco and mx51_efikamx too

Signed-off-by: Chris Kuethe chris.kue...@gmail.com
Cc: Tom Rini tr...@konsulko.com
Cc: Matthew Starr mst...@hedonline.com
Cc: Andrej Rosano and...@inversepath.com
Cc: Stefano Babic sba...@denx.de
Cc: Chris Kuethe chris.kue...@gmail.com
Cc: Fabio Estevam feste...@gmail.com
Cc: Marek Vasut ma...@denx.de

diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index f059d0f..5f0e1e6 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -9,6 +9,8 @@

 #define ARCH_MXC

+#define CONFIG_SYS_CACHELINE_SIZE 64
+
 #if defined(CONFIG_MX51)
 #define IRAM_BASE_ADDR 0x1FFE  /* internal ram */
 #define IPU_SOC_BASE_ADDR  0x4000


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] patch: fix typo in mxc_hab docs

[Ulises Cardenas]

Hi Chris,

On 6/2/2015 3:44 PM, Chris Kuethe wrote:

diff --git a/doc/README.mxc_hab b/doc/README.mxc_hab
index a1b1d34..5fe977c 100644
--- a/doc/README.mxc_hab
+++ b/doc/README.mxc_hab
@@ -69,7 +69,7 @@ CONFIG_SECURE_BOOT
  CONFIG_SYS_FSL_SEC_COMPAT4 /* HAB version */
  CONFIG_FSL_CAAM
  CONFIG_CMD_DEKBLOB
-CONFIG_SYS_FSL_LE
+CONFIG_SYS_FSL_SEC_LE

  Note: The encrypted boot feature is only supported by HABv4 or
  greater.
This fix was already committed and applied to the repository. In the 
following commit:

8148b824492e7696a9e72bb5b715720db8fd889e

Please pull the latest source code, you will see the changes.

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

[U-Boot] [PATCHv4 3/3] arm: socfpga: enable the Altera SDRAM controller driver

[dinguyen]

From: Dinh Nguyen dingu...@opensource.altera.com

Enable the Altera SDRAM driver for the SoCFPGA platform.

Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
Acked-by: Marek Vasut ma...@denx.de
---
 include/configs/socfpga_common.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index cae744d..9b52050 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -77,6 +77,11 @@
 #define CONFIG_SYS_PL310_BASE  SOCFPGA_MPUL2_ADDRESS
 
 /*
+ * SDRAM controller
+ */
+#define CONFIG_ALTERA_SDRAM
+
+/*
  * EPCS/EPCQx1 Serial Flash Controller
  */
 #ifdef CONFIG_ALTERA_SPI
-- 
2.2.1

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

[U-Boot] [PATCHv4 0/3] drivers/ddr/altera: Add the DDR controller driver for SoCFPGA

[dinguyen]

From: Dinh Nguyen dingu...@opensource.altera.com

Hi,

This is v4 of the patch series that adds the DDR controller driver for
Altera's SoCFPGA platform.

v4:
- Further cleanup by removing comments that do not apply for Cyclone5.
- Removed more unused functions

Thanks,

Dinh Nguyen (3):
  driver/ddr/altera: Add DDR driver for Altera's SDRAM controller
  driver/ddr/altera: Add the sdram calibration portion
  arm: socfpga: enable the Altera SDRAM controller driver

 Makefile |1 +
 arch/arm/include/asm/arch-socfpga/sdram.h|  306 ++
 arch/arm/include/asm/arch-socfpga/sdram_config.h |  100 +
 drivers/ddr/altera/Makefile  |   11 +
 drivers/ddr/altera/sdram.c   |  799 +
 drivers/ddr/altera/sequencer.c   | 4051 ++
 drivers/ddr/altera/sequencer.h   |  322 ++
 drivers/ddr/altera/sequencer_auto.h  |  128 +
 drivers/ddr/altera/sequencer_auto_ac_init.h  |   84 +
 drivers/ddr/altera/sequencer_auto_inst_init.h|  268 ++
 drivers/ddr/altera/sequencer_defines.h   |  121 +
 include/configs/socfpga_common.h |5 +
 scripts/Makefile.spl |1 +
 13 files changed, 6197 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-socfpga/sdram.h
 create mode 100644 arch/arm/include/asm/arch-socfpga/sdram_config.h
 create mode 100644 drivers/ddr/altera/Makefile
 create mode 100644 drivers/ddr/altera/sdram.c
 create mode 100644 drivers/ddr/altera/sequencer.c
 create mode 100644 drivers/ddr/altera/sequencer.h
 create mode 100644 drivers/ddr/altera/sequencer_auto.h
 create mode 100644 drivers/ddr/altera/sequencer_auto_ac_init.h
 create mode 100644 drivers/ddr/altera/sequencer_auto_inst_init.h
 create mode 100644 drivers/ddr/altera/sequencer_defines.h

-- 
2.2.1

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

[U-Boot] [PATCHv4 1/3] driver/ddr/altera: Add DDR driver for Altera's SDRAM controller

[dinguyen]

From: Dinh Nguyen dingu...@opensource.altera.com

This patch enables the SDRAM controller that is used on Altera's SoCFPGA
family. This patch configures the SDRAM controller based on a configuration
file that is generated from the Quartus tool, sdram_config.h.

Signed-off-by: Dinh Nguyen dingu...@opensource.altera.com
---
v4: none
v3: none
v2: clean up from comments from Pavel
---
 Makefile |   1 +
 arch/arm/include/asm/arch-socfpga/sdram.h| 306 +
 arch/arm/include/asm/arch-socfpga/sdram_config.h | 100 +++
 drivers/ddr/altera/sdram.c   | 799 +++
 scripts/Makefile.spl |   1 +
 5 files changed, 1207 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-socfpga/sdram.h
 create mode 100644 arch/arm/include/asm/arch-socfpga/sdram_config.h
 create mode 100644 drivers/ddr/altera/sdram.c

diff --git a/Makefile b/Makefile
index 0f7d583..163d530 100644
--- a/Makefile
+++ b/Makefile
@@ -649,6 +649,7 @@ libs-y += drivers/power/ \
 libs-y += drivers/spi/
 libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
 libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
+libs-$(CONFIG_ALTERA_SDRAM) += drivers/ddr/altera/
 libs-y += drivers/serial/
 libs-y += drivers/usb/dwc3/
 libs-y += drivers/usb/eth/
diff --git a/arch/arm/include/asm/arch-socfpga/sdram.h 
b/arch/arm/include/asm/arch-socfpga/sdram.h
new file mode 100644
index 000..b4c1a2f
--- /dev/null
+++ b/arch/arm/include/asm/arch-socfpga/sdram.h
@@ -0,0 +1,306 @@
+/*
+ * Copyright Altera Corporation (C) 2014-2015
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#ifndef_SDRAM_H_
+#define_SDRAM_H_
+
+#ifndef __ASSEMBLY__
+
+unsigned long sdram_calculate_size(void);
+unsigned sdram_mmr_init_full(unsigned int sdr_phy_reg);
+int sdram_calibration_full(void);
+
+extern int sdram_calibration(void);
+
+#define SDR_CTRLGRP_ADDRESS 0x5000
+
+struct socfpga_sdr_ctrl {
+   u32 ctrl_cfg;
+   u32 dram_timing1;
+   u32 dram_timing2;
+   u32 dram_timing3;
+   u32 dram_timing4;   /* 0x10 */
+   u32 lowpwr_timing;
+   u32 dram_odt;
+   u32 __padding0[4];
+   u32 dram_addrw; /* 0x2c */
+   u32 dram_if_width;  /* 0x30 */
+   u32 dram_dev_width;
+   u32 dram_sts;
+   u32 dram_intr;
+   u32 sbe_count;  /* 0x40 */
+   u32 dbe_count;
+   u32 err_addr;
+   u32 drop_count;
+   u32 drop_addr;  /* 0x50 */
+   u32 lowpwr_eq;
+   u32 lowpwr_ack;
+   u32 static_cfg;
+   u32 ctrl_width; /* 0x60 */
+   u32 cport_width;
+   u32 cport_wmap;
+   u32 cport_rmap;
+   u32 rfifo_cmap; /* 0x70 */
+   u32 wfifo_cmap;
+   u32 cport_rdwr;
+   u32 port_cfg;
+   u32 fpgaport_rst;   /* 0x80 */
+   u32 __padding1;
+   u32 fifo_cfg;
+   u32 protport_default;
+   u32 prot_rule_addr; /* 0x90 */
+   u32 prot_rule_id;
+   u32 prot_rule_data;
+   u32 prot_rule_rdwr;
+   u32 __padding2[3];
+   u32 mp_priority;/* 0xac */
+   u32 mp_weight0; /* 0xb0 */
+   u32 mp_weight1;
+   u32 mp_weight2;
+   u32 mp_weight3;
+   u32 mp_pacing0; /* 0xc0 */
+   u32 mp_pacing1;
+   u32 mp_pacing2;
+   u32 mp_pacing3;
+   u32 mp_threshold0;  /* 0xd0 */
+   u32 mp_threshold1;
+   u32 mp_threshold2;
+   u32 __padding3[29];
+   u32 phy_ctrl0;  /* 0x150 */
+   u32 phy_ctrl1;
+   u32 phy_ctrl2;
+};
+
+struct sdram_prot_rule {
+   uint64_tsdram_start; /* SDRAM start address */
+   uint64_tsdram_end; /* SDRAM end address */
+   uint32_trule; /* SDRAM protection rule number: 0-19 */
+   int valid; /* Rule valid or not? 1 - valid, 0 not*/
+
+   uint32_tsecurity;
+   uint32_tportmask;
+   uint32_tresult;
+   uint32_tlo_prot_id;
+   uint32_thi_prot_id;
+};
+
+#define SDR_CTRLGRP_CTRLCFG_NODMPINS_LSB 23
+#define SDR_CTRLGRP_CTRLCFG_NODMPINS_MASK 0x0080
+#define SDR_CTRLGRP_CTRLCFG_DQSTRKEN_LSB 22
+#define SDR_CTRLGRP_CTRLCFG_DQSTRKEN_MASK 0x0040
+#define SDR_CTRLGRP_CTRLCFG_STARVELIMIT_LSB 16
+#define SDR_CTRLGRP_CTRLCFG_STARVELIMIT_MASK 0x003f
+#define SDR_CTRLGRP_CTRLCFG_REORDEREN_LSB 15
+#define SDR_CTRLGRP_CTRLCFG_REORDEREN_MASK 0x8000
+#define SDR_CTRLGRP_CTRLCFG_ECCCORREN_LSB 11
+#define SDR_CTRLGRP_CTRLCFG_ECCCORREN_MASK 0x0800
+#define SDR_CTRLGRP_CTRLCFG_ECCEN_LSB 10
+#define SDR_CTRLGRP_CTRLCFG_ECCEN_MASK 0x0400
+#define SDR_CTRLGRP_CTRLCFG_ADDRORDER_LSB 8
+#define SDR_CTRLGRP_CTRLCFG_ADDRORDER_MASK 0x0300
+#define SDR_CTRLGRP_CTRLCFG_MEMBL_LSB 3
+#define SDR_CTRLGRP_CTRLCFG_MEMBL_MASK 0x00f8
+#define 

[U-Boot] [PATCH] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Bin Meng]

The following error is observed on QEMU x86.

= print ipaddr
ipaddr=192.168.178.66
= ping 192.168.178.1
*** ERROR: `ipaddr' not set
ping failed; host 192.168.178.1 is not alive

The issue was introduced in commit fd30563. Adding CMD_NET to
defconfig resolves this. Also reorder the config options to
match the order in Kconfig.

Signed-off-by: Bin Meng bmeng...@gmail.com
---

 configs/qemu-x86_defconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index a5251b5..07b5176 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -1,9 +1,9 @@
 CONFIG_X86=y
 CONFIG_VENDOR_EMULATION=y
 CONFIG_TARGET_QEMU_X86=y
+CONFIG_GENERATE_PIRQ_TABLE=y
+CONFIG_CMD_NET=y
 CONFIG_OF_CONTROL=y
-CONFIG_OF_SEPARATE=y
 CONFIG_VIDEO_VESA=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_FRAMEBUFFER_VESA_MODE_111=y
-CONFIG_GENERATE_PIRQ_TABLE=y
-- 
1.8.2.1

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

Re: [U-Boot] [PATCH] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Bin Meng]

Hi Simon,

On Tue, Jun 2, 2015 at 6:40 PM, Bin Meng bmeng...@gmail.com wrote:
 The following error is observed on QEMU x86.

 = print ipaddr
 ipaddr=192.168.178.66
 = ping 192.168.178.1
 *** ERROR: `ipaddr' not set
 ping failed; host 192.168.178.1 is not alive

 The issue was introduced in commit fd30563. Adding CMD_NET to
 defconfig resolves this. Also reorder the config options to
 match the order in Kconfig.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  configs/qemu-x86_defconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
 index a5251b5..07b5176 100644
 --- a/configs/qemu-x86_defconfig
 +++ b/configs/qemu-x86_defconfig
 @@ -1,9 +1,9 @@
  CONFIG_X86=y
  CONFIG_VENDOR_EMULATION=y
  CONFIG_TARGET_QEMU_X86=y
 +CONFIG_GENERATE_PIRQ_TABLE=y
 +CONFIG_CMD_NET=y
  CONFIG_OF_CONTROL=y
 -CONFIG_OF_SEPARATE=y
  CONFIG_VIDEO_VESA=y
  CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
  CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 -CONFIG_GENERATE_PIRQ_TABLE=y
 --

After Joe's pull request [1] get applied by Tom, you can rebase
u-boot-x86/testing branch and apply this one to fix the qemu
networking issue. Thanks!

[1] http://patchwork.ozlabs.org/patch/479136/

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

Re: [U-Boot] [PATCH v2 2/2] configs: remove CONFIG_NET_MULTI

[Viresh Kumar]

On 02-06-15, 11:25, poesc...@lemonage.de wrote:
 From: Lars Poeschel poesc...@lemonage.de
 
 CONFIG_NET_MULTI is not used anywhere and thus can safely be removed
 from the configs.

  include/configs/spear-common.h | 1 -

Acked-by: Viresh Kumar viresh.ku...@linaro.org

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

[U-Boot] [PATCH v2 2/2] configs: remove CONFIG_NET_MULTI

[poeschel]

From: Lars Poeschel poesc...@lemonage.de

CONFIG_NET_MULTI is not used anywhere and thus can safely be removed
from the configs.

Signed-off-by: Lars Poeschel poesc...@lemonage.de
---
 include/configs/B4860QDS.h | 1 -
 include/configs/C29XPCIE.h | 1 -
 include/configs/M54418TWR.h| 1 -
 include/configs/T208xQDS.h | 1 -
 include/configs/T208xRDB.h | 1 -
 include/configs/T4240RDB.h | 1 -
 include/configs/ac14xx.h   | 1 -
 include/configs/adp-ag102.h| 1 -
 include/configs/alt.h  | 1 -
 include/configs/am43xx_evm.h   | 1 -
 include/configs/apx4devkit.h   | 1 -
 include/configs/armadillo-800eva.h | 1 -
 include/configs/atngw100mkii.h | 1 -
 include/configs/axs101.h   | 1 -
 include/configs/bf609-ezkit.h  | 1 -
 include/configs/bg0900.h   | 1 -
 include/configs/edb93xx.h  | 1 -
 include/configs/gose.h | 1 -
 include/configs/ids8313.h  | 1 -
 include/configs/ima3-mx53.h| 1 -
 include/configs/integratorap.h | 1 -
 include/configs/koelsch.h  | 1 -
 include/configs/ks2_evm.h  | 1 -
 include/configs/kzm9g.h| 1 -
 include/configs/lager.h| 1 -
 include/configs/ls1021aqds.h   | 1 -
 include/configs/ls1021atwr.h   | 1 -
 include/configs/ls2085aqds.h   | 1 -
 include/configs/ls2085ardb.h   | 1 -
 include/configs/mx28evk.h  | 1 -
 include/configs/omapl138_lcdk.h| 1 -
 include/configs/p1_twr.h   | 5 -
 include/configs/pcm051.h   | 1 -
 include/configs/porter.h   | 1 -
 include/configs/qemu-ppce500.h | 1 -
 include/configs/sama5d3_xplained.h | 1 -
 include/configs/siemens-am33x-common.h | 1 -
 include/configs/silk.h | 1 -
 include/configs/socfpga_common.h   | 1 -
 include/configs/spear-common.h | 1 -
 include/configs/t4qds.h| 1 -
 include/configs/ti814x_evm.h   | 1 -
 include/configs/vl_ma2sc.h | 1 -
 include/configs/x600.h | 1 -
 include/configs/zynq-common.h  | 1 -
 45 files changed, 49 deletions(-)

diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index dca1ca5..35824af 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -719,7 +719,6 @@ unsigned long get_board_ddr_clk(void);
 
 #ifdef CONFIG_PCI
 #define CONFIG_PCI_INDIRECT_BRIDGE
-#define CONFIG_NET_MULTI
 #define CONFIG_PCI_PNP /* do pci plug-and-play */
 #define CONFIG_E1000
 
diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h
index 7c45c36..f63fe7e 100644
--- a/include/configs/C29XPCIE.h
+++ b/include/configs/C29XPCIE.h
@@ -441,7 +441,6 @@
 #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
 
 #ifdef CONFIG_TSEC_ENET
-#define CONFIG_NET_MULTI
 #define CONFIG_MII /* MII PHY management */
 #define CONFIG_MII_DEFAULT_TSEC1   /* Allow unregistered phys */
 #define CONFIG_TSEC1   1
diff --git a/include/configs/M54418TWR.h b/include/configs/M54418TWR.h
index 25b3cda..275aa4e 100644
--- a/include/configs/M54418TWR.h
+++ b/include/configs/M54418TWR.h
@@ -79,7 +79,6 @@
 /* Network configuration */
 #define CONFIG_MCFFEC
 #ifdef CONFIG_MCFFEC
-#define CONFIG_NET_MULTI   1
 #define CONFIG_MII 1
 #define CONFIG_MII_INIT1
 #define CONFIG_SYS_DISCOVER_PHY
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index bad3613..a43d958 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -620,7 +620,6 @@ unsigned long get_board_ddr_clk(void);
 #ifdef CONFIG_PCI
 #define CONFIG_PCI_INDIRECT_BRIDGE
 #define CONFIG_FSL_PCIE_RESET /* need PCIe reset errata */
-#define CONFIG_NET_MULTI
 #define CONFIG_E1000
 #define CONFIG_PCI_PNP /* do pci plug-and-play */
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h
index 107efdc..a5f2f23 100644
--- a/include/configs/T208xRDB.h
+++ b/include/configs/T208xRDB.h
@@ -568,7 +568,6 @@ unsigned long get_board_ddr_clk(void);
 #ifdef CONFIG_PCI
 #define CONFIG_PCI_INDIRECT_BRIDGE
 #define CONFIG_FSL_PCIE_RESET   /* need PCIe reset errata LSZ ADD */
-#define CONFIG_NET_MULTI
 #define CONFIG_E1000
 #define CONFIG_PCI_PNP /* do pci plug-and-play */
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h
index 2a22249..19dc332 100644
--- a/include/configs/T4240RDB.h
+++ b/include/configs/T4240RDB.h
@@ -277,7 +277,6 @@
 
 #ifdef CONFIG_PCI
 #define CONFIG_PCI_INDIRECT_BRIDGE
-#define CONFIG_NET_MULTI
 #define CONFIG_PCI_PNP /* do pci plug-and-play */
 #define CONFIG_E1000
 
diff --git 

Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

[Simon Glass]

Hi Bin,

On 2 June 2015 at 08:15, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Thu, May 28, 2015 at 1:46 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 27 May 2015 at 10:17, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:37 PM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 26 May 2015 at 21:50, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com wrote:
 Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
 U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/coreboot/coreboot.c | 4 
  1 file changed, 4 deletions(-)

 diff --git a/arch/x86/cpu/coreboot/coreboot.c 
 b/arch/x86/cpu/coreboot/coreboot.c
 index 4cdd0d4..2234cf0 100644
 --- a/arch/x86/cpu/coreboot/coreboot.c
 +++ b/arch/x86/cpu/coreboot/coreboot.c
 @@ -85,10 +85,6 @@ void board_final_cleanup(void)
 wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
 mtrr_close(state);
 }
 -
 -   /* Issue SMI to Coreboot to lock down ME and registers */
 -   printf(Finalizing Coreboot\n);
 -   outb(0xcb, 0xb2);
  }

  void panic_puts(const char *str)
 --
 1.8.2.1


 But how does this run with coreboot on platforms that need it? Should
 this be controlled by a device tree settings, perhaps?


 I am not sure if the lock down should be done by the coreboot in the
 first place. IMHO U-Boot as the coreboot payload should not touch such
 low-level stuff.

 Well it is telling coreboot that it is about to boot the kernel. I
 think this is an x86 thing and we should support it.


 What happens if coreboot directly boot into the kernel? Does coreboot
 do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My

 Kind of, although in that case it is just a function call within coreboot.

 understanding is that coreboot payload is to enhance coreboot's
 functionality as a system BIOS (either having legacy BIOS interface
 with the help of a SeaBIOS payload, or having UEFI interface with the
 help of a TinaoCore payload). coreboot itself does the mainboard
 initialization and payload does something that is not hardware
 dependent.

 Right, but we need to tell coreboot that we have finished with the ME
 / registers, etc. It can't lock them before calling U-Boot since we
 may adjust them.


 Will use a config option in the device tree in v2.

OK thanks. When you resend can you please rebase on x86/master?

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

Re: [U-Boot] [PATCH 2/6] x86: qemu: Adjust VGA initialization

[Simon Glass]

On 26 May 2015 at 21:13, Simon Glass s...@chromium.org wrote:
 On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com wrote:
 As VGA option rom needs to run at C segment, although QEMU PAM emulation
 seems to only guard E/F segments, for correctness, move VGA initialization
 after PAM decode C/D/E/F segments.

 Also since we already tested QEMU targets to differentiate I440FX and Q35
 platforms, change to locate the VGA device via hardcoded b.d.f instead of
 dynamic search for its vendor id  device id pair.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/qemu/pci.c | 34 
 +++--
  arch/x86/include/asm/arch-qemu/device.h |  2 ++
  2 files changed, 17 insertions(+), 19 deletions(-)

 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH 1/6] x86: qemu: Enable legacy IDE I/O ports decode

[Simon Glass]

On 26 May 2015 at 21:13, Simon Glass s...@chromium.org wrote:
 On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com wrote:
 QEMU always decode legacy IDE I/O ports on PIIX chipset. However Linux 
 ata_piix
 driver does sanity check to see whether legacy ports decode is turned on.
 To make Linux ata_piix driver happy, turn on the decode via IDE_TIMING 
 register.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/qemu/pci.c | 14 ++
  arch/x86/include/asm/arch-qemu/device.h | 19 +++
  arch/x86/include/asm/arch-qemu/qemu.h   |  5 +
  3 files changed, 38 insertions(+)
  create mode 100644 arch/x86/include/asm/arch-qemu/device.h

 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 2/2] x86: qemu: Turn on legacy segments decode

[Simon Glass]

On 23 May 2015 at 10:12, Bin Meng bmeng...@gmail.com wrote:
 By default the legacy segments C/D/E/F do not decode to system RAM.
 Turn on the decode via Programmable Attribute Map (PAM) registers
 so that we can write configuration tables in the F segment.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 Acked-by: Simon Glass s...@chromium.org

 ---

 Changes in v2: None

  arch/x86/cpu/qemu/pci.c   | 20 
  arch/x86/include/asm/arch-qemu/qemu.h |  6 ++
  2 files changed, 26 insertions(+)

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

Re: [U-Boot] [PATCH] ARM: phytec: pcm051: select board revision by Kconfig

[Tom Rini]

On Mon, Jun 01, 2015 at 05:09:11PM +0200, poesc...@lemonage.de wrote:

 From: Lars Poeschel poesc...@lemonage.de
 
 This add a Kconfig entry that allows to set the board revision in
 menuconfig. So the deprecated CONFIG_SYS_EXTRA_OPTIONS is no longer
 needed for this boad.
 
 Signed-off-by: Lars Poeschel poesc...@lemonage.de

I like the concept but CONFIG_REVx is way too generic.  Can we maybe
re-work things as CONFIG_TARGET_PCM051_REV1 / CONFIG_TARGET_PCM051_REV3
(and those select CONFIG_TARGET_PCM051) ?  Masahiro?  Thanks!

 ---
  board/phytec/pcm051/Kconfig   | 19 +++
  configs/pcm051_rev1_defconfig |  2 +-
  configs/pcm051_rev3_defconfig |  2 +-
  3 files changed, 21 insertions(+), 2 deletions(-)
 
 diff --git a/board/phytec/pcm051/Kconfig b/board/phytec/pcm051/Kconfig
 index 2cc0d88..c1071c6 100644
 --- a/board/phytec/pcm051/Kconfig
 +++ b/board/phytec/pcm051/Kconfig
 @@ -12,4 +12,23 @@ config SYS_SOC
  config SYS_CONFIG_NAME
   default pcm051
  
 +choice
 +prompt pcm051 revision select
 +default REV3
 +
 +config REV1
 + bool pcm051 revision 1 or 2
 + help
 +   If you have 1358.1 written on the pcb of your pcm051, you
 +   have a revision 1 board. Likewise if you have 1358.2 on your
 +   board, it is a revision 2 board and this entry is for you.
 +
 +config REV3
 + bool pcm051 revision 3
 + help
 +   If you have 1358.3 written on the pcb of your pcm051, you
 +   have a revision 3 board and you have to select this entry.
 +
 +endchoice
 +
  endif
 diff --git a/configs/pcm051_rev1_defconfig b/configs/pcm051_rev1_defconfig
 index af02b2f..0a28195 100644
 --- a/configs/pcm051_rev1_defconfig
 +++ b/configs/pcm051_rev1_defconfig
 @@ -1,4 +1,4 @@
  CONFIG_ARM=y
  CONFIG_TARGET_PCM051=y
  CONFIG_SPL=y
 -CONFIG_SYS_EXTRA_OPTIONS=REV1
 +CONFIG_REV1=y
 diff --git a/configs/pcm051_rev3_defconfig b/configs/pcm051_rev3_defconfig
 index 2a907d7..4ad49df 100644
 --- a/configs/pcm051_rev3_defconfig
 +++ b/configs/pcm051_rev3_defconfig
 @@ -1,4 +1,4 @@
  CONFIG_ARM=y
  CONFIG_TARGET_PCM051=y
  CONFIG_SPL=y
 -CONFIG_SYS_EXTRA_OPTIONS=REV3
 +CONFIG_REV3=y
 -- 
 2.1.4
 
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

-- 
Tom


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

Re: [U-Boot] [PATCH v2 3/4] x86: quark: Implement PIRQ routing

[Simon Glass]

On 25 May 2015 at 08:35, Bin Meng bmeng...@gmail.com wrote:
 Intel Quark SoC has the same interrupt routing mechanism as the
 Queensbay platform, only the difference is that PCI devices'
 INTA/B/C/D are harcoded and cannot be changed freely.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 Acked-by: Simon Glass s...@chromium.org

 ---

 Changes in v2: None

  arch/x86/cpu/quark/quark.c   | 31 ++
  arch/x86/dts/galileo.dts | 22 ++
  arch/x86/include/asm/arch-quark/device.h | 70 
 +---
  arch/x86/include/asm/arch-quark/quark.h  | 15 +++
  configs/galileo_defconfig|  1 +
  include/configs/galileo.h|  1 +
  6 files changed, 125 insertions(+), 15 deletions(-)


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

Re: [U-Boot] [PATCH v2 2/4] x86: Document irq router device tree bindings

[Simon Glass]

On 25 May 2015 at 08:35, Bin Meng bmeng...@gmail.com wrote:
 Describe all required properties needed by the irq router device tree.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 Acked-by: Simon Glass s...@chromium.org

 ---

 Changes in v2:
 - Fix typo of 'configuration'

  doc/device-tree-bindings/misc/intel,irq-router.txt | 50 
 ++
  1 file changed, 50 insertions(+)
  create mode 100644 doc/device-tree-bindings/misc/intel,irq-router.txt

 diff --git a/doc/device-tree-bindings/misc/intel,irq-router.txt 
 b/doc/device-tree-bindings/misc/intel,irq-router.txt
 new file mode 100644
 index 000..598b4b1
 --- /dev/null
 +++ b/doc/device-tree-bindings/misc/intel,irq-router.txt
 @@ -0,0 +1,50 @@
 +Intel Interrupt Router Device Binding
 +=
 +
 +The device tree node which describes the operation of the Intel Interrupt 
 Router
 +device is as follows:
 +
 +Required properties :
 +- reg : Specifies the interrupt router's PCI configuration space address as
 +defined by the Open Firmware spec.
 +- compatible = intel,irq-router
 +- intel,pirq-config : Specifies the IRQ routing register programming 
 mechanism.
 +Valid values are:
 +  pci: IRQ routing is controlled by PCI configuration registers
 +  ibase: IRQ routing is in the memory-mapped IBASE register block
 +- intel,ibase-offset : IBASE register offset in the interrupt router's PCI
 +configuration space, required only if intel,pirq-config = ibase.
 +- intel,pirq-link : Specifies the PIRQ link information with two cells. The
 +first cell is the register offset that controls the first PIRQ link 
 routing.
 +The second cell is the total number of PIRQ links the router supports.
 +- intel,pirq-mask : Specifies the IRQ mask reprenting the 16 IRQs in 8259 
 PIC.
 +Bit N is 1 means IRQ N is available to be routed.
 +- intel,pirq-routing : Specifies all PCI devices' IRQ routing information,
 +   encoded as 3 cells a group for a device. The first cell is the device's 
 PCI
 +   bus number, device number and function number encoding with PCI_BDF() 
 macro.
 +   The second cell is the PCI interrupt pin used by this device. The last 
 cell
 +   is which PIRQ line the PCI interrupt pin is routed to.
 +
 +
 +Example
 +---
 +
 +#include dt-bindings/interrupt-router/intel-irq.h
 +
 +   irq-router@1f,0 {
 +   reg = 0xf800 0 0 0 0;
 +   compatible = intel,irq-router;
 +   intel,pirq-config = pci;
 +   intel,pirq-link = 0x60 8;
 +   intel,pirq-mask = 0xdef8;
 +   intel,pirq-routing = 
 +   PCI_BDF(0, 2, 0) INTA PIRQA
 +   PCI_BDF(0, 3, 0) INTA PIRQB
 +   PCI_BDF(0, 8, 0) INTA PIRQC
 +   PCI_BDF(0, 8, 1) INTB PIRQD
 +   PCI_BDF(1, 6, 0) INTA PIRQE
 +   PCI_BDF(1, 6, 1) INTB PIRQF
 +   PCI_BDF(1, 6, 2) INTC PIRQG
 +   PCI_BDF(1, 6, 3) INTD PIRQH
 +   ;
 +   };
 --
 1.8.2.1


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

Re: [U-Boot] [PATCH 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

[Bin Meng]

Hi Simon,

On Tue, Jun 2, 2015 at 10:20 PM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 2 June 2015 at 08:15, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Thu, May 28, 2015 at 1:46 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 27 May 2015 at 10:17, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:37 PM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 26 May 2015 at 21:50, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com wrote:
 Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) 
 causes
 U-Boot to hang on QEMU q35 target. Disable the writing for QEMU 
 targets.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/coreboot/coreboot.c | 4 
  1 file changed, 4 deletions(-)

 diff --git a/arch/x86/cpu/coreboot/coreboot.c 
 b/arch/x86/cpu/coreboot/coreboot.c
 index 4cdd0d4..2234cf0 100644
 --- a/arch/x86/cpu/coreboot/coreboot.c
 +++ b/arch/x86/cpu/coreboot/coreboot.c
 @@ -85,10 +85,6 @@ void board_final_cleanup(void)
 wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
 mtrr_close(state);
 }
 -
 -   /* Issue SMI to Coreboot to lock down ME and registers */
 -   printf(Finalizing Coreboot\n);
 -   outb(0xcb, 0xb2);
  }

  void panic_puts(const char *str)
 --
 1.8.2.1


 But how does this run with coreboot on platforms that need it? Should
 this be controlled by a device tree settings, perhaps?


 I am not sure if the lock down should be done by the coreboot in the
 first place. IMHO U-Boot as the coreboot payload should not touch such
 low-level stuff.

 Well it is telling coreboot that it is about to boot the kernel. I
 think this is an x86 thing and we should support it.


 What happens if coreboot directly boot into the kernel? Does coreboot
 do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My

 Kind of, although in that case it is just a function call within coreboot.

 understanding is that coreboot payload is to enhance coreboot's
 functionality as a system BIOS (either having legacy BIOS interface
 with the help of a SeaBIOS payload, or having UEFI interface with the
 help of a TinaoCore payload). coreboot itself does the mainboard
 initialization and payload does something that is not hardware
 dependent.

 Right, but we need to tell coreboot that we have finished with the ME
 / registers, etc. It can't lock them before calling U-Boot since we
 may adjust them.


 Will use a config option in the device tree in v2.

 OK thanks. When you resend can you please rebase on x86/master?


Yes, already rebased :-)

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

Re: [U-Boot] [PATCH v2 4/4] x86: Do sanity test on pirq table before writing

[Simon Glass]

On 25 May 2015 at 08:35, Bin Meng bmeng...@gmail.com wrote:
 If pirq_routing_table points to NULL, that means U-Boot fails to
 generate the table before in create_pirq_routing_table(), so we
 test it against NULL before actually writing it.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 Acked-by: Simon Glass s...@chromium.org
 ---

 Changes in v2: None

  arch/x86/cpu/irq.c | 3 +++
  1 file changed, 3 insertions(+)

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

Re: [U-Boot] [PATCH cosmetic] x86: fsp_support: Correct high mem comment typo

[Simon Glass]

On 23 May 2015 at 10:37, Simon Glass s...@chromium.org wrote:
 On 23 May 2015 at 09:44, Bin Meng bmeng...@gmail.com wrote:
 +Simon.

 On Sat, May 23, 2015 at 3:11 AM,  and...@bradfordembedded.com wrote:
 From: Andrew Bradford andrew.bradf...@kodakalaris.com

 High mem starts at 4 GiB.

 Signed-off-by: Andrew Bradford andrew.bradf...@kodakalaris.com
 ---
  arch/x86/lib/fsp/fsp_support.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
 index 5f96da1..5809235 100644
 --- a/arch/x86/lib/fsp/fsp_support.c
 +++ b/arch/x86/lib/fsp/fsp_support.c
 @@ -279,7 +279,7 @@ u64 fsp_get_usable_highmem_top(const void *hob_list)
 res_desc = (struct hob_res_desc *)hdr;
 if (res_desc-type == RES_SYS_MEM) {
 phys_start = res_desc-phys_start;
 -   /* Need memory above 1MB to be collected 
 here */
 +   /* Need memory above 4GB to be collected 
 here */
 if (phys_start = 
 (phys_addr_t)FSP_HIGHMEM_BASE)
 top += (u32)(res_desc-len);
 }
 --

 Reviewed-by: Bin Meng bmeng...@gmail.com

 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 1/2] x86: qemu: Make host bridge (b.d.f=0.0.0) visible

[Simon Glass]

On 23 May 2015 at 10:37, Simon Glass s...@chromium.org wrote:
 On 23 May 2015 at 10:12, Bin Meng bmeng...@gmail.com wrote:
 The default weak version of pci_skip_dev() in drivers/pci/pci_common.c
 skips the host bridge (b.d.f = 0.0.0) which is actually the i440fx/q35
 chipset for QEMU targets. Define CONFIG_PCI_CONFIG_HOST_BRIDGE to make
 it visible in the PCI configuration space.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2:
 - Change to use CONFIG_PCI_CONFIG_HOST_BRIDGE

  include/configs/qemu-x86.h   | 1 +
  include/configs/x86-common.h | 1 +
  2 files changed, 2 insertions(+)

 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] Booting Wandboard through USB

[Tom Rini]

On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
[snip]
 Honestly I've never used fsl's mfgtool and never want to. I think its
 way more complicated than a scrip-table linux solution with very few
 dependencies (imx_usb_loader) and IMHO I think we should not be
 encumbered with fitting that complicated mould but instead work on
 breaking it by providing better options.

The counter-point that we can't just dismiss is that we want companies
on mainline.  Today many use the Freescale mfgtool (which is a big
wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
into Linux and then flashing the board.  A solution that continues to
work within this framework removes a barrier from getting them on
mainline (and from Freescale shipping a more recent version of U-Boot
with their refernce SW).

Thinking about this a bit, as near as I can tell the way the mfgtool
(and for that matter, imx_usb_loader when passing in multiple files)
works is to use the header of u-boot.imx (or whatever...) to initialize
DDR, then start taking files and putting them in.  Could we not add some
debug (or opt-in CONFIG statement) that would cause SPL to spit out in
essence the values to plug into a template for header-based DDR init?
That way the mfgtool itself will continue working and instead of being
told to use u-boot.imx it's given a script (which iirc it supports) and
u-boot.img to run and it's normal loads of everything to flash.  Roughly
speaking :)

-- 
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 3/6] x86: coreboot: Don't write I/O port 0xb2 for QEMU targets

[Bin Meng]

Hi Simon,

On Thu, May 28, 2015 at 1:46 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 27 May 2015 at 10:17, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:37 PM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 26 May 2015 at 21:50, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Wed, May 27, 2015 at 11:13 AM, Simon Glass s...@chromium.org wrote:
 Hi Bin,

 On 25 May 2015 at 08:36, Bin Meng bmeng...@gmail.com wrote:
 Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
 U-Boot to hang on QEMU q35 target. Disable the writing for QEMU targets.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  arch/x86/cpu/coreboot/coreboot.c | 4 
  1 file changed, 4 deletions(-)

 diff --git a/arch/x86/cpu/coreboot/coreboot.c 
 b/arch/x86/cpu/coreboot/coreboot.c
 index 4cdd0d4..2234cf0 100644
 --- a/arch/x86/cpu/coreboot/coreboot.c
 +++ b/arch/x86/cpu/coreboot/coreboot.c
 @@ -85,10 +85,6 @@ void board_final_cleanup(void)
 wrmsrl(MTRR_PHYS_MASK_MSR(top_mtrr), 0);
 mtrr_close(state);
 }
 -
 -   /* Issue SMI to Coreboot to lock down ME and registers */
 -   printf(Finalizing Coreboot\n);
 -   outb(0xcb, 0xb2);
  }

  void panic_puts(const char *str)
 --
 1.8.2.1


 But how does this run with coreboot on platforms that need it? Should
 this be controlled by a device tree settings, perhaps?


 I am not sure if the lock down should be done by the coreboot in the
 first place. IMHO U-Boot as the coreboot payload should not touch such
 low-level stuff.

 Well it is telling coreboot that it is about to boot the kernel. I
 think this is an x86 thing and we should support it.


 What happens if coreboot directly boot into the kernel? Does coreboot
 do the same 'outb(0xcb, 0xb2)' thing before jumping to kernel? My

 Kind of, although in that case it is just a function call within coreboot.

 understanding is that coreboot payload is to enhance coreboot's
 functionality as a system BIOS (either having legacy BIOS interface
 with the help of a SeaBIOS payload, or having UEFI interface with the
 help of a TinaoCore payload). coreboot itself does the mainboard
 initialization and payload does something that is not hardware
 dependent.

 Right, but we need to tell coreboot that we have finished with the ME
 / registers, etc. It can't lock them before calling U-Boot since we
 may adjust them.


Will use a config option in the device tree in v2.

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

Re: [U-Boot] [PATCH v2 5/6] x86: Add CONFIG_LBA48 and remove CONFIG_ATAPI in x86-common.h

[Simon Glass]

On 18 May 2015 at 15:39, Simon Glass s...@chromium.org wrote:
 On 15 May 2015 at 19:33, Bin Meng bmeng...@gmail.com wrote:
 Enable CONFIG_LBA48 to support large disks. CONFIG_ATAPI is only needed
 by cmd_ide.c which is not common for modern x86 targets, hence remove it.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

 Changes in v2: None

  include/configs/x86-common.h | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

 diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
 index 0b61615..3912b39 100644
 --- a/include/configs/x86-common.h
 +++ b/include/configs/x86-common.h
 @@ -37,6 +37,7 @@
  #define CONFIG_SCSI_AHCI
  #ifdef CONFIG_SCSI_AHCI
  #define CONFIG_LIBATA
 +#define CONFIG_LBA48
  #define CONFIG_SYS_64BIT_LBA

  #define CONFIG_SYS_SCSI_MAX_SCSI_ID2
 @@ -76,10 +77,6 @@
  #define CONFIG_SYS_HUSH_PARSER

  #define CONFIG_SUPPORT_VFAT
 -/
 - * ATAPI support (experimental)
 - /
 -#define CONFIG_ATAPI

  /
   * DISK Partition support
 --
 1.8.2.1


 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 1/6] pci: Allow debug message output in pci_auto.c

[Simon Glass]

On 18 May 2015 at 15:39, Simon Glass s...@chromium.org wrote:
 On 15 May 2015 at 19:33, Bin Meng bmeng...@gmail.com wrote:
 Remove the '#undef DEBUG' in pci_auto.c so that we can enable debug
 message output via '-DDEBUG'.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2:
 - Commit meessage minor update

  drivers/pci/pci_auto.c | 1 -
  1 file changed, 1 deletion(-)

 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 1/4] x86: Refactor PIRQ routing support

[Simon Glass]

On 26 May 2015 at 14:58, Simon Glass s...@chromium.org wrote:
 On 25 May 2015 at 08:35, Bin Meng bmeng...@gmail.com wrote:
 PIRQ routing is pretty much common in Intel chipset. It has several
 PIRQ links (normally 8) and corresponding registers (either in PCI
 configuration space or memory-mapped IBASE) to configure the legacy
 8259 IRQ vector mapping. Refactor current Queensbay PIRQ routing
 support using device tree and move it to a common place, so that we
 can easily add PIRQ routing support on a new platform.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2:
 - Include dt-bindings/interrupt-router/intel-irq.h to avoid duplication
 - Remove board_fill_irq_info() since all routing information is defined in 
 dts

  arch/x86/cpu/Makefile|   2 +-
  arch/x86/cpu/irq.c   | 213 
  arch/x86/cpu/queensbay/Makefile  |   2 +-
  arch/x86/cpu/queensbay/irq.c | 242 
 ---
  arch/x86/cpu/queensbay/tnc.c |  39 +++-
  arch/x86/dts/crownbay.dts|  54 +
  arch/x86/include/asm/arch-queensbay/irq.h|  55 --
  arch/x86/include/asm/irq.h   |  76 +++
  include/dt-bindings/interrupt-router/intel-irq.h |  31 +++
  include/fdtdec.h |   1 +
  lib/fdtdec.c |   1 +
  11 files changed, 416 insertions(+), 300 deletions(-)
  create mode 100644 arch/x86/cpu/irq.c
  delete mode 100644 arch/x86/cpu/queensbay/irq.c
  delete mode 100644 arch/x86/include/asm/arch-queensbay/irq.h
  create mode 100644 arch/x86/include/asm/irq.h
  create mode 100644 include/dt-bindings/interrupt-router/intel-irq.h


 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 4/6] cmd_ide: Eliminate build warnings in atapi_inquiry()

[Simon Glass]

On 18 May 2015 at 15:39, Simon Glass s...@chromium.org wrote:
 On 15 May 2015 at 19:33, Bin Meng bmeng...@gmail.com wrote:
 Eliminate the following build warning in atapi_inquiry():
   warning: assignment from incompatible pointer type [enabled by default]

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2:
 - Correct the typo of 'Eliminate' in the commit message

  common/cmd_ide.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/common/cmd_ide.c b/common/cmd_ide.c
 index 04a6d9b..ecd3e9d 100644
 --- a/common/cmd_ide.c
 +++ b/common/cmd_ide.c
 @@ -79,7 +79,7 @@ static void ident_cpy (unsigned char *dest, unsigned char 
 *src, unsigned int len

  #ifdef CONFIG_ATAPI
  static voidatapi_inquiry(block_dev_desc_t *dev_desc);
 -static ulong atapi_read(int device, ulong blknr, lbaint_t blkcnt,
 +static ulong atapi_read(int device, lbaint_t blknr, lbaint_t blkcnt,
 void *buffer);
  #endif

 @@ -1388,13 +1388,13 @@ static void atapi_inquiry(block_dev_desc_t *dev_desc)
  #define ATAPI_READ_BLOCK_SIZE  2048/* assuming CD part */
  #define ATAPI_READ_MAX_BLOCK   (ATAPI_READ_MAX_BYTES/ATAPI_READ_BLOCK_SIZE)

 -ulong atapi_read(int device, ulong blknr, lbaint_t blkcnt, void *buffer)
 +ulong atapi_read(int device, lbaint_t blknr, lbaint_t blkcnt, void *buffer)
  {
 ulong n = 0;
 unsigned char ccb[12];  /* Command descriptor block */
 ulong cnt;

 -   debug(atapi_read dev %d start %lX, blocks  LBAF  buffer at %lX\n,
 +   debug(atapi_read dev %d start  LBAF  blocks  LBAF  buffer at 
 %lX\n,
   device, blknr, blkcnt, (ulong) buffer);

 do {
 --
 1.8.2.1


 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH v2 6/6] x86: qemu: Add ATA/SATA support

[Simon Glass]

On 18 May 2015 at 15:40, Simon Glass s...@chromium.org wrote:
 On 15 May 2015 at 19:33, Bin Meng bmeng...@gmail.com wrote:
 Enable legacy IDE support on the pc target and AHCI support on the
 q35 target. Default configuration is to support the pc target.

 Signed-off-by: Bin Meng bmeng...@gmail.com

 ---

 Changes in v2: None

  include/configs/qemu-x86.h | 26 +-
  include/pci_ids.h  |  1 +
  2 files changed, 26 insertions(+), 1 deletion(-)


 Acked-by: Simon Glass s...@chromium.org

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

Re: [U-Boot] [PATCH] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Bin Meng]

Hi Simon,

On Tue, Jun 2, 2015 at 6:44 PM, Bin Meng bmeng...@gmail.com wrote:
 Hi Simon,

 On Tue, Jun 2, 2015 at 6:40 PM, Bin Meng bmeng...@gmail.com wrote:
 The following error is observed on QEMU x86.

 = print ipaddr
 ipaddr=192.168.178.66
 = ping 192.168.178.1
 *** ERROR: `ipaddr' not set
 ping failed; host 192.168.178.1 is not alive

 The issue was introduced in commit fd30563. Adding CMD_NET to
 defconfig resolves this. Also reorder the config options to
 match the order in Kconfig.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---

  configs/qemu-x86_defconfig | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
 index a5251b5..07b5176 100644
 --- a/configs/qemu-x86_defconfig
 +++ b/configs/qemu-x86_defconfig
 @@ -1,9 +1,9 @@
  CONFIG_X86=y
  CONFIG_VENDOR_EMULATION=y
  CONFIG_TARGET_QEMU_X86=y
 +CONFIG_GENERATE_PIRQ_TABLE=y
 +CONFIG_CMD_NET=y
  CONFIG_OF_CONTROL=y
 -CONFIG_OF_SEPARATE=y
  CONFIG_VIDEO_VESA=y
  CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
  CONFIG_FRAMEBUFFER_VESA_MODE_111=y
 -CONFIG_GENERATE_PIRQ_TABLE=y
 --

 After Joe's pull request [1] get applied by Tom, you can rebase
 u-boot-x86/testing branch and apply this one to fix the qemu
 networking issue. Thanks!

 [1] http://patchwork.ozlabs.org/patch/479136/


I see Joe's pull request has been applied, but sorry I've noticed that
this patch has some dependencies on the qemu v2 patch series I am
working on. Please ignore this and I will resend it as part of my qemu
v2 patch series soon. Sorry about that.

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

Re: [U-Boot] [PATCH] sunxi: Add new Mele_A1000G_quad defconfig

[Tom Rini]

On Tue, Jun 02, 2015 at 09:07:53AM +0200, Hans de Goede wrote:
 Hi,
 
 On 01-06-15 22:46, Tom Rini wrote:
 On Mon, Jun 01, 2015 at 08:19:23PM +0200, Hans de Goede wrote:
 Hi,
 
 On 01-06-15 20:12, Ian Campbell wrote:
 On Mon, 2015-06-01 at 17:01 +0200, Hans de Goede wrote:
 The Mele A1000G-quad and the Mele M9 have the same PCB, sofar we've been
 using the same defconfig (and dts on the kernel side) for both models.
 Unfortunately this does not work for the otg controller, on the M9 this
 is routed to a micro-usb connector on the outside, while as on the
 A1000G-quad it is connected to an usb to sata bridge.
 
 This commit adds a new defconfig for the Mele-A1000G-quad to allow using
 different otg controller settings on the 2 boards.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 diff --git a/configs/Mele_A1000G_quad_defconfig 
 b/configs/Mele_A1000G_quad_defconfig
 new file mode 100644
 index 000..b93dcf5
 --- /dev/null
 +++ b/configs/Mele_A1000G_quad_defconfig
 @@ -0,0 +1,24 @@
 +# The Mele A1000G quad is yet another Allwinnner based Android top set 
 box
 +# from Mele.
 +#
 +# It uses the same case as the original Mele A1000 and the same PCB as 
 the M9,
 +# the  USM sata storage slot is connected via anusb to sata bridge 
 connected to
 +# the otg controller, this renders the micro USB B receptacle non 
 functional.
 +#
 +# It features an A31 SoC, 2G RAM, 16G Nand, 100Mbit ethernet, HDMI out,
 +# 3 USB A receptacles, 3.5 mm jack for analog audio out, optical spdif,
 +# RTL R8188EU (USB) wifi and a full size sdcard slot
 
 Have you seen the thread Clean all defconfigs with savedefconfig which
 we were copied on today? It seems that these comments are subject to
 automated cleansing :-/
 
 Explictly adding Tom to the list of recipients
 
 Tom, do we really want some autofoobar tool to mangle our defconfigs? Is 
 there
 a way we can opt out of this ?
 
 Reasons to opt out:
 
 1) Having comments like the one above on top of the defconfig files makes
 it much easier for people to check if they are selecting the right defconfig
 
 2) We deliberately duplicate some settings in defconfig files even though
 they are the default since new users submitting new boards tend to copy and
 paste an existing defconfig of a similar board and this way they have a 
 short
 list of settings to check against the actual board, because their board may
 not be using the reference design pins which we use as defaults ...
 
 So personally as sunxi maintainer I would like to opt out of this automatic
 destruction of useful info in our defconfigs ...
 
 So, historically people have put a lot of odds and ends info into either
 include/configs/board.h or boards/vendor/board/board.c.  With Kconfig
 we're moving away from the former and with things like sunxi where we
 just slightly tweak some parameters to run on many boards we don't have
 the latter the question is where to place otherwise generally useful
 info.
 
 The problem, to expand on what I said in the other thread, is that
 *_defconfig is treated as an auto-generated file in Kbuild projects (I
 know the kernel and I'm pretty sure elsewhere too).  This is only going
 to get more noticable as we convert things over to real Kconfig choices,
 meaning that if we opt-out of changing sunxi configs they're going to
 get broken or make the conversion harder for everyone else.
 
 We should be able to add say board/sunxi/README.txt and keep it
 formatted such that new entries go on the bottom and have a predefined
 separator at the end so that adding more boards doesn't conflict.
 
 If we stuff everything in one file people need to match which board
 description belongs to which defconfig manually at which point
 we might just as well point them to the linux-sunxi.org wiki
 which has all this info + actual pictures of the devices.
 
 So if there is no way to store this info in the defconfigs lets
 just leave it out and will point people to the wiki.

Yes, wiki it is then, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request: u-boot-sh/rmobile

[Tom Rini]

On Mon, Jun 01, 2015 at 12:19:17PM +0900, Nobuhiro Iwamatsu wrote:

 Dear Tom Rini.
 
 Please pull u-boot-sh rmobile branch.
 
 The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:
 
   am33xx, spl, siemens: enable debug uart output again (2015-05-28
 08:18:25 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-sh.git rmobile
 
 for you to fetch changes up to a5aef732066c6de0d2466174fb017e8a6fb0267a:
 
   arm: rmobile: alt: Update to QoS revision 0.31 and 0.321 (2015-06-01
 08:56:34 +0900)
 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Pull request: u-boot-net.git master

[Tom Rini]

On Mon, Jun 01, 2015 at 01:24:00PM -0500, Joe Hershberger wrote:

 Hi Tom,
 
 This should include the few build fixes that have been submitted as
 well as fixing up Michal's patch to the LIB_RAND dependency patch.
 
 It also cleans up the CONFIG_NET/CONFIG_CMD_NET situation that was
 breaking networking for a number of boards.
 
 I've included the CMD_SETEXPR patch in this since it would otherwise
 create patch conflicts if done separately.
 
 The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:
 
   am33xx, spl, siemens: enable debug uart output again (2015-05-28
 08:18:25 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-net.git master
 
 for you to fetch changes up to 9ba9e85f3f1cc2e7d8b387a03c50eb067d915e0a:
 
   net: Fix NET_RANDOM_ETHADDR dependencies (2015-06-01 13:15:11 -0500)
 

Applied to u-boot/master and fixed up include/configs/unipher.h, thanks!

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

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

[Tom Rini]

On Fri, May 29, 2015 at 01:18:10PM +0200, Marek Vasut wrote:

 Tom, let me know if this builds please.
 
 The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:
 
   am33xx, spl, siemens: enable debug uart output again (2015-05-28 08:18:25 
 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-usb.git HEAD
 
 for you to fetch changes up to 8454c84af5401f8c3bcd0ed2625043270d0ef6aa:
 
   usb: kbd: Fix key repeat not always working (2015-05-29 12:41:05 +0200)
 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] cosmetic: change Author/MAINTAINER Name from Petermaier to Schmelzer

[Tom Rini]

On Thu, May 28, 2015 at 03:41:12PM +0200, Hannes Schmelzer wrote:

 From: Hannes Schmelzer hannes.schmel...@br-automation.com
 
 Since i've been married, i also have a new surname.
 Mr. Petermaier moved to Mr. Schmelzer.
 
 In this patch i update all files in which my (old) name is present.
 
 Signed-off-by: Hannes Schmelzer hannes.schmel...@br-automation.com
 
 Signed-off-by: Hannes Schmelzer oe5...@oevsv.at

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] pull request: u-boot-uniphier/master

[Tom Rini]

On Sun, May 31, 2015 at 03:05:17AM +0900, Masahiro Yamada wrote:

 Hi Tom,
 
 Please pull u-boot-uniphier/master.
 
 
 The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:
 
   am33xx, spl, siemens: enable debug uart output again (2015-05-28
 08:18:25 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-uniphier.git master
 
 for you to fetch changes up to fcb2525d373f7a5bab213e8a89681bd3b7d09c44:
 
   ARM: UniPhier: add pin mux setting for NAND CS1 of PH1-Pro4
 (2015-05-31 02:56:02 +0900)
 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-sunxi master

[Tom Rini]

On Sat, May 30, 2015 at 11:18:04AM +0200, Hans de Goede wrote:

 Hi Tom,
 
 Please pull u-boot-sunxi/master into master for a number of
 patch-sets which have been in the making for a long time and
 are now ready for merging.
 
 Highlights:
 - A80 (suni9i) SoC support (u-boot.bin only, no SPL support yet)
 - SPL nand support (support loading u-boot.bin from nand)
 - PSCI support for sun6i, sun8i-a23 and sun8i-a33 SoCs
 
 The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:
 
   am33xx, spl, siemens: enable debug uart output again (2015-05-28 08:18:25 
 -0400)
 
 are available in the git repository at:
 
   http://git.denx.de/u-boot-sunxi.git master
 
 for you to fetch changes up to 014414f53695ab3ba5a9d344ad1ba8952bce157c:
 
   ARM: sunxi: Enable PSCI for sun8i (2015-05-29 13:46:36 +0200)
 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] moveconfig: Add a new --git-ref option

[Joe Hershberger]

Hey guys,

On Fri, May 29, 2015 at 4:23 PM, Joe Hershberger joe.hershber...@ni.com wrote:
 This option allows the 'make *_defconfig' step to run against a former
 repo state, while the savedefconfig step runs against the current repo
 state. This is convenient for the case where something in the Kconfig
 has changed such that the defconfig is no longer complete with the new
 Kconfigs. This feature allows the .config to be built assuming those old
 Kconfigs, but then savedefconfig based on the new state of the Kconfigs.

 Signed-off-by: Joe Hershberger joe.hershber...@ni.com
 ---

I forgot the Cc's on this...

  tools/moveconfig.py | 60 
 +
  tools/patman/gitutil.py | 15 +
  2 files changed, 71 insertions(+), 4 deletions(-)

 diff --git a/tools/moveconfig.py b/tools/moveconfig.py
 index 496c90a..eeb9c0e 100755
 --- a/tools/moveconfig.py
 +++ b/tools/moveconfig.py
 @@ -153,6 +153,10 @@ Available options
 Specify the number of threads to run simultaneously.  If not specified,
 the number of threads is the same as the number of CPU cores.

 + -r, --git-ref
 +   Specify the git ref to clone for the make *_defconfig step. If unspecified
 +   use the CWD.
 +
   -v, --verbose
 Show any build errors as boards are built

 @@ -173,6 +177,12 @@ import sys
  import tempfile
  import time

 +# Bring in the patman libraries
 +our_path = os.path.dirname(os.path.realpath(__file__))
 +sys.path.append(os.path.join(our_path, 'patman'))
 +
 +import gitutil
 +
  SHOW_GNU_MAKE = 'scripts/show-gnu-make'
  SLEEP_TIME=0.03

 @@ -526,7 +536,7 @@ class Slot:
  for faster processing.
  

 -def __init__(self, config_attrs, options, devnull, make_cmd):
 +def __init__(self, config_attrs, options, devnull, make_cmd, 
 defconfig_src_dir):
  Create a new process slot.

  Arguments:
 @@ -540,6 +550,7 @@ class Slot:
  self.build_dir = tempfile.mkdtemp()
  self.devnull = devnull
  self.make_cmd = (make_cmd, 'O=' + self.build_dir)
 +self.defconfig_src_dir = defconfig_src_dir
  self.parser = KconfigParser(config_attrs, options, self.build_dir)
  self.state = STATE_IDLE
  self.failed_boards = []
 @@ -576,6 +587,9 @@ class Slot:
  return False
  cmd = list(self.make_cmd)
  cmd.append(defconfig)
 +if self.options.git_ref:
 +cmd.append('-C')
 +cmd.append(self.defconfig_src_dir)
  self.ps = subprocess.Popen(cmd, stdout=self.devnull,
 stderr=subprocess.PIPE)
  self.defconfig = defconfig
 @@ -658,6 +672,9 @@ class Slot:
  cmd.append('include/config/auto.conf')
  This will be screen-scraped, so be sure the expected text will be
  returned consistently on every machine by setting LANG=C
 +if self.options.git_ref:
 +cmd.append('-C')
 +cmd.append(self.defconfig_src_dir)
  self.ps = subprocess.Popen(cmd, stdout=self.devnull,
 env=dict(os.environ, LANG='C'),
 stderr=subprocess.PIPE)
 @@ -673,7 +690,7 @@ class Slots:

  Controller of the array of subprocess slots.

 -def __init__(self, config_attrs, options):
 +def __init__(self, config_attrs, options, defconfig_src_dir):
  Create a new slots controller.

  Arguments:
 @@ -686,7 +703,8 @@ class Slots:
  devnull = get_devnull()
  make_cmd = get_make_cmd()
  for i in range(options.jobs):
 -self.slots.append(Slot(config_attrs, options, devnull, make_cmd))
 +self.slots.append(Slot(config_attrs, options, devnull, make_cmd,
 +   defconfig_src_dir))

  def add(self, defconfig, num, total):
  Add a new subprocess if a vacant slot is found.
 @@ -743,6 +761,24 @@ class Slots:
  for board in failed_boards:
  f.write(board + '\n')

 +class WorkDir:
 +def __init__(self):
 +Create a new working directory.
 +self.work_dir = tempfile.mkdtemp()
 +
 +def __del__(self):
 +Delete the working directory
 +
 +This function makes sure the temporary directory is cleaned away
 +even if Python suddenly dies due to error.  It should be done in here
 +because it is guaranteed the destructor is always invoked when the
 +instance of the class gets unreferenced.
 +
 +shutil.rmtree(self.work_dir)
 +
 +def get(self):
 +return self.work_dir
 +
  def move_config(config_attrs, options):
  Move config options to defconfig files.

 @@ -755,6 +791,20 @@ def move_config(config_attrs, options):
  print 'Nothing to do. exit.'
  sys.exit(0)

 +defconfig_src_dir = ''
 +
 +if options.git_ref:
 +work_dir = WorkDir()
 +defconfig_src_dir = work_dir.get()
 +

[U-Boot] iMX6 - CONFIG_SYS_GENERIC_BOARD macro defined in U-Boot

[ansaris]

Hi,

We are using imx6Q SabreSD platform for our development with 
U-Boot-2014.04.  But initially we used U-Boot-2013.04 version.


We have gone through below file in U-Boot-2014.04 and found that the 
CONFIG_SYS_GENERIC_BOARD macro is defined.

~/u-boot-imx/include/configs/mx6sabre_common.h

Because of the macro CONFIG_SYS_GENERIC_BOARD definition, the 
board_init_f and board_init_r functions are executed from the below 
files respectively.

~/u-boot-imx/common/board_f.c
~/u-boot-imx/common/board_r.c

But we have gone through below file in U-Boot-2013.04 and found that the 
CONFIG_SYS_GENERIC_BOARD macro is not defined.

~/u-boot-imx/include/configs/mx6qsabre_common.h
With U-Boot-2013.04, the board_init_f and board_init_r functions are 
executed from the below file

~/u-boot-imx/arch/arm/lib/board.c

Please clarify our below doubt.
From U-Boot-2014.04, why the board_init_f and board_init_r 
functions are not executed from below file.

~/u-boot-imx/arch/arm/lib/board.c

Please suggest us.

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

[U-Boot] iMX6 - CONFIG_SYS_GENERIC_BOARD macro defined in U-Boot

[ansaris]

Hi,

We are using imx6Q SabreSD platform for our development with
U-Boot-2014.04.  But initially we used U-Boot-2013.04 version.

We have gone through below file in U-Boot-2014.04 and found that the
CONFIG_SYS_GENERIC_BOARD macro is defined.
~/u-boot-imx/include/configs/mx6sabre_common.h

Because of the macro CONFIG_SYS_GENERIC_BOARD definition, the
board_init_f and board_init_r functions are executed from the below
files respectively.
~/u-boot-imx/common/board_f.c
~/u-boot-imx/common/board_r.c

But we have gone through below file in U-Boot-2013.04 and found that the
CONFIG_SYS_GENERIC_BOARD macro is not defined.
~/u-boot-imx/include/configs/mx6qsabre_common.h
With U-Boot-2013.04, the board_init_f and board_init_r functions are
executed from the below file
~/u-boot-imx/arch/arm/lib/board.c

Please clarify our below doubt.
From U-Boot-2014.04, why the board_init_f and board_init_r
functions are not executed from below file.
~/u-boot-imx/arch/arm/lib/board.c

Please suggest us.

Thanks and Regards,
Ansari

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

Re: [U-Boot] [PATCH v2 2/2] configs: remove CONFIG_NET_MULTI

[Marek Vasut]

On Tuesday, June 02, 2015 at 11:25:54 AM, poesc...@lemonage.de wrote:
 From: Lars Poeschel poesc...@lemonage.de
 
 CONFIG_NET_MULTI is not used anywhere and thus can safely be removed
 from the configs.
 
 Signed-off-by: Lars Poeschel poesc...@lemonage.de

Acked-by: Marek Vasut ma...@denx.de

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/2] configs: remove CONFIG_NET_MULTI

[Tom Rini]

On Tue, Jun 02, 2015 at 11:25:54AM +0200, poesc...@lemonage.de wrote:

 From: Lars Poeschel poesc...@lemonage.de
 
 CONFIG_NET_MULTI is not used anywhere and thus can safely be removed
 from the configs.
 
 Acked-by: Viresh Kumar viresh.ku...@linaro.org
 Acked-by: Marek Vasut ma...@denx.de
 Signed-off-by: Lars Poeschel poesc...@lemonage.de

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] CPCI4052: Remove CONFIG_SYS_LONGHELP

[Tom Rini]

With the change to make sure that CONFIG_CMD_NET is enabled this board
no longer fits into the linker script:

powerpc-linux-ld.bfd: section .resetvec loaded at [fffc,] overlaps 
section .u_boot_list loaded at [ff58,0723]
powerpc-linux-ld.bfd: u-boot: section .resetvec lma 0xfffc adjusted to 0x724
powerpc-linux-ld.bfd: u-boot: section `.resetvec' can't be allocated in segment 0
LOAD: .data.init .text .rodata .reloc .data .u_boot_list .resetvec
powerpc-linux-ld.bfd: final link failed: File truncated

Drop CONFIG_SYS_LONGHELP to free up space.

Cc: Matthias Fuchs matthias.fu...@esd-electronics.com
Signed-off-by: Tom Rini tr...@konsulko.com
---
 include/configs/CPCI4052.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/CPCI4052.h b/include/configs/CPCI4052.h
index ceddd7a..a1bc3db 100644
--- a/include/configs/CPCI4052.h
+++ b/include/configs/CPCI4052.h
@@ -94,7 +94,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_SYS_LONGHELP/* undef to save memory 
*/
+#undef CONFIG_SYS_LONGHELP /* undef to save memory 
*/
 
 #undef CONFIG_SYS_HUSH_PARSER  /* use hush command parser
*/
 
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v2 1/2] ARM: phytec: pcm051: Remove unneeded CONFIG_USE_IRQ

[Tom Rini]

On Tue, Jun 02, 2015 at 11:23:04AM +0200, poesc...@lemonage.de wrote:

 From: Lars Poeschel poesc...@lemonage.de
 
 The config for pcm051 still undef'd CONFIG_USE_IRQ. This is not
 needed any more since it is not defined in the whole include path
 before.
 
 Signed-off-by: Lars Poeschel poesc...@lemonage.de

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Tue, Jun 2, 2015 at 7:25 AM, Tom Rini tr...@konsulko.com wrote:
 On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
 [snip]
 Honestly I've never used fsl's mfgtool and never want to. I think its
 way more complicated than a scrip-table linux solution with very few
 dependencies (imx_usb_loader) and IMHO I think we should not be
 encumbered with fitting that complicated mould but instead work on
 breaking it by providing better options.

 The counter-point that we can't just dismiss is that we want companies
 on mainline.  Today many use the Freescale mfgtool (which is a big
 wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
 into Linux and then flashing the board.  A solution that continues to
 work within this framework removes a barrier from getting them on
 mainline (and from Freescale shipping a more recent version of U-Boot
 with their refernce SW).

mfgtool is a big 'windows' wrapper around shoving a u-boot.imx over
USB OTG and scripting through serial port to do 'whatever else' is
needed. While fsl may be getting close to mainline that doesn't mean
they are using SPL and thats the difference here.


 Thinking about this a bit, as near as I can tell the way the mfgtool
 (and for that matter, imx_usb_loader when passing in multiple files)
 works is to use the header of u-boot.imx (or whatever...) to initialize
 DDR, then start taking files and putting them in.  Could we not add some
 debug (or opt-in CONFIG statement) that would cause SPL to spit out in
 essence the values to plug into a template for header-based DDR init?
 That way the mfgtool itself will continue working and instead of being
 told to use u-boot.imx it's given a script (which iirc it supports) and
 u-boot.img to run and it's normal loads of everything to flash.  Roughly
 speaking :)

 --
 Tom

mfgmode uses a windows exe that takes a *.imx which has a DCD table
and sets the regs defined in the DCD table - so it relies on the
non-SPL way of doing things where the MMDC configuration is hard-coded
in the DCD, thus every combination of SoC 'type'
(IMX6DQ|IMX6SDL|IMX6SX) and memory configuration
(chip+width+calib-for-pcb+size) requires a different DCD thus *.imx.

To my knowledge fsl has not 'embraced the SPL' and is still relying on
custom DCD's in the bootloader (someone please correct me if I'm out
of date here). That thought works just fine for customers in large
vertical markets with one or two configs but is very inflexible for
those of us that vary the parameters quite a bit.

The imx_usb_loader works off the assumption that you have a DCD (which
is just a table of register addr's and values) and that the DCD
configures the MMDC properly for your target, so that it can then load
1 or more blobs into DRAM. In our case what we are wanting to do is
let the SPL configure the MMDC then use the SPL to allow a raw DRAM
load option over OTG. I don't see any other way to do it other than
Nikolay's idea which should not be that difficult to implement. I
don't know enough about mfgtool to know how flexible it is. Can you
build imx_usb_loader for windows and choose to use an 'enhanced one'
vs the closed-source one distributed with mfgtool and thus continue to
use the config/scripting portion of the mfgtool package?

It 'could' be possible to make the SPL output all its register writes
I suppose through some wrappers around writel (I've actually done this
in the past to troubleshoot things) to re-create a DCD but I'm not
sure I see the point in where we go from there as you would also need
the SPL to not re-configure the MMDC and not clobber memory so
essentially your no longer using the SPL.

If someone wants to use mfgtool they can go down the path of non-SPL
U-Boot's and be fine. If someone wants to use SPL why can't we provide
a better/different approach? Perhaps fsl can release the source for
mfgtools windows cmdline app so that it can be enahnced to support
this as well.

I've run into a similar issue with fsl's 'ddr calibration and stress
test tool' because I think it uses the same approach to mfgtool (it
may even use the same windows exe). The windows tool loads their
stand-alone bare-metal blob (has a DCD so equiv to an *.imx) over OTG
then the bare-metal app immediately implements a USB HID-generic
gadget over OTG and communicates to the windows app that way
(basically serial-console over USB at that point). Now, if you are
able to get the source for the ddr calibration and stress test tool
from fsl (not too hard) you can build it in a way that it doesn't have
the DCD and doesn't use the USB OTG HID-generic gadget as a serial
console and then load it via U-Boot or JTAG (of course in that mode
U-Boot or JTAG needs to be doing what the DCD did to configure the
MMDC so you can run into a catch-22 scenario if your trying to use the
tool to obtain those DDC values). When you get the source for this
tool, its just the source for the bare-metal app not the Windows exe
that is used with it. The only reason 

Re: [U-Boot] [PATCHv2] board: Add Toby-Churchill SL50 board support.

[Tom Rini]

On Thu, May 28, 2015 at 02:47:52PM +0200, Enric Balletbo i Serra wrote:

 Add support for Lightwriter SL50 series board, a small, robust and portable
 Voice Output Communication Aids (VOCA) designed to meet the particular and
 changing needs of people with speech loss resulting from a wide range of
 acquired, progressive and congenital conditions.
 
 Signed-off-by: Enric Balletbo i Serra enric.balle...@collabora.com
[snip]
 +++ b/board/tcl/sl50/mux.c
[snip]
 +++ b/include/configs/am335x_sl50.h

In addition to Sjoerd's comments, these two files don't have SPDX tags
but instead the full verbage, please fix, thanks!

-- 
Tom


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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Saket Sinha]

Hi John,

  Can you punt me a copy of the image so I can try it here
 and double check?

 Please see below for the drive link.
 
  https://drive.google.com/file/d/0B7WYZbZ9zd-3eDFaNHpFN2JrcUE/view?usp=sharing

Are you able to see any output with Simon's u-boot.rom shared above on
the serial?

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

Re: [U-Boot] [PATCH] arm: dcc: Add uart dcc support for armv8

[Tom Rini]

On Fri, May 29, 2015 at 09:54:37AM +0200, Michal Simek wrote:

 From: Siva Durga Prasad Paladugu siva.durga.palad...@xilinx.com
 
 Added UART DCC support for armv8
 
 Signed-off-by: Siva Durga Prasad Paladugu siva...@xilinx.com
 Signed-off-by: Michal Simek michal.si...@xilinx.com

Reviewed-by: Tom Rini tr...@konsulko.com

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

Re: [U-Boot] [PATCH] spi: cadence_qspi: Fix the indirect ahb trigger address setting

[Vikas MANOCHA]

Hi Graham,

 -Original Message-
 From: Stefan Roese [mailto:s...@denx.de]
 Sent: Monday, June 01, 2015 4:34 AM
 To: Vikas MANOCHA; u-boot@lists.denx.de; Graham Moore
 Cc: Dinh Nguyen; Marek Vasut
 Subject: Re: [PATCH] spi: cadence_qspi: Fix the indirect ahb trigger address
 setting
 
 Hi Vikas,
 
 On 29.05.2015 18:53, vikasm wrote:
  On 05/28/2015 11:20 PM, Stefan Roese wrote:
  Hi Vikas,
 
  (added Dinh, Graham and Marek to Cc)
 
  On 29.05.2015 03:22, Vikas Manocha wrote:
  Trigger base address can be set to the spi flash address without any
  masking, here is the explanation of the register.
 
  QSPI_IND_AHB_ADDR_TRIGGER :
  Trigger Address is the base address that is used by the AHB
  controller for indirect accesses. When the incoming AHB access
  address matches a range of addresses from this trigger address to
  the trigger address + 15, then the AHB request is completed by
 fetching/storing data from/to the Controllers SRAM.
 
  Signed-off-by: Vikas Manocha vikas.mano...@st.com
  ---
 drivers/spi/cadence_qspi_apb.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/spi/cadence_qspi_apb.c
  b/drivers/spi/cadence_qspi_apb.c index 00a115f..855e5c7 100644
  --- a/drivers/spi/cadence_qspi_apb.c
  +++ b/drivers/spi/cadence_qspi_apb.c
  @@ -50,7 +50,6 @@
 #define CQSPI_INST_TYPE_QUAD   (2)
 
 #define CQSPI_STIG_DATA_LEN_MAX(8)
  -#define CQSPI_INDIRECTTRIGGER_ADDR_MASK  (0xF)
 
 #define CQSPI_DUMMY_CLKS_PER_BYTE  (8)
 #define CQSPI_DUMMY_BYTES_MAX  (4)
  @@ -697,8 +696,7 @@ int
 cadence_qspi_apb_indirect_read_setup(struct cadence_spi_platdata *plat,
addr_bytes = cmdlen - 1;
 
/* Setup the indirect trigger address */
  - writel(((u32)plat-ahbbase 
 CQSPI_INDIRECTTRIGGER_ADDR_MASK),
  -plat-regbase + CQSPI_REG_INDIRECTTRIGGER);
  + writel((u32)plat-ahbbase, plat-regbase +
  +CQSPI_REG_INDIRECTTRIGGER);
 
/* Configure SRAM partition for read. */
writel(CQSPI_REG_SRAM_PARTITION_RD, plat-regbase + @@ -
 798,8
  +796,7 @@ int cadence_qspi_apb_indirect_write_setup(struct
 cadence_spi_platdata *plat,
return -EINVAL;
}
/* Setup the indirect trigger address */
  - writel(((u32)plat-ahbbase 
 CQSPI_INDIRECTTRIGGER_ADDR_MASK),
  -plat-regbase + CQSPI_REG_INDIRECTTRIGGER);
  + writel((u32)plat-ahbbase, plat-regbase +
  +CQSPI_REG_INDIRECTTRIGGER);
  Might I ask on which SoC you are using this driver? Which problem are
  you experiencing exactly?
 
  I am using ST's soc stv0991. The spi flash memory is mapped at address
  0x4000_. By Masking with 0xF_, the value to be loaded in the
  indirect trigger register becomes zero  then spi read/write does not
  work. By removing or changing the mask to 0x_, the loaded
  value in indirect trigger register is 0x4000_  spi read/write works 
  fine.
 
  It should be same of socfpga also after masking with 0xF_,
  wondering how it works there.
 
 Yes, I'm wondering a bit myself. Thats why I added Graham to Cc as he is the
 author of the original driver. And knows this far better than I do.
 
  No masking is done in the driver while polling fifo for read/write,
  plat-ahbbase was used directly. Any idea why this masking was done
  for ahb trigger base register?
 
 Graham? Do you have any insight here please?

Any idea ?

Rgds,
Vikas

 
 Thanks,
 Stefan

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Simon Glass]

Hi Saket,

On 2 June 2015 at 09:44, Saket Sinha saket.sinh...@gmail.com wrote:

 Hi John,

   Can you punt me a copy of the image so I can try it here
  and double check?
 
  Please see below for the drive link.
  
   https://drive.google.com/file/d/0B7WYZbZ9zd-3eDFaNHpFN2JrcUE/view?usp=sharing

 Are you able to see any output with Simon's u-boot.rom shared above on
 the serial?

Also do you know which MinnowMAX board you have? I think there are two versions.

I might be able to create an image that prints out post_code() calls.

Will wait to hear from John.

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Saket Sinha]

Hi Simon,


 Also do you know which MinnowMAX board you have? I think there are two 
 versions.

The pcb  does not speak of any particular versions.

I found there are two hardware revisions -
 http://www.elinux.org/Minnowboard:Hardware_Revisions#MinnowMax

But I would not be able to tell my minnowmax belongs to which revision
without the Multimeter and other stuff which currently I am not
possessing.

Moreover, the changes are not of the nature to have stopped the u-boot
from booting.


 I might be able to create an image that prints out post_code() calls.


That would be a real help.

 Will wait to hear from John.


Same here.

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

[U-Boot] [PATCH 1/2] arm: Add ENTRY/ENDPROC to private libgcc functions

[Simon Glass]

When CONFIG_SYS_THUMB_BUILD is defined these functions may be called from
Thumb code. Add the required ENTRY and ENDPROC bracketing so that BLX is
used to call these ARM functions, instead of plain BL, which will fail.

Signed-off-by: Simon Glass s...@chromium.org
Reported-by: Pavel Machek pa...@denx.de
---

 arch/arm/lib/_ashldi3.S |  6 --
 arch/arm/lib/_ashrdi3.S |  6 --
 arch/arm/lib/_divsi3.S  |  6 --
 arch/arm/lib/_lshrdi3.S |  6 --
 arch/arm/lib/_modsi3.S  |  7 ---
 arch/arm/lib/_udivsi3.S | 10 ++
 arch/arm/lib/_umodsi3.S |  6 --
 7 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/arch/arm/lib/_ashldi3.S b/arch/arm/lib/_ashldi3.S
index 2c26f84..9c34c21 100644
--- a/arch/arm/lib/_ashldi3.S
+++ b/arch/arm/lib/_ashldi3.S
@@ -4,6 +4,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include linux/linkage.h
+
 #ifdef __ARMEB__
 #define al r1
 #define ah r0
@@ -13,9 +15,8 @@
 #endif
 
 .globl __ashldi3
-.globl __aeabi_llsl
 __ashldi3:
-__aeabi_llsl:
+ENTRY(__aeabi_llsl)
 
subsr3, r2, #32
rsb ip, r2, #32
@@ -24,3 +25,4 @@ __aeabi_llsl:
orrmi   ah, ah, al, lsr ip
mov al, al, lsl r2
mov pc, lr
+ENDPROC(__aeabi_llsl)
diff --git a/arch/arm/lib/_ashrdi3.S b/arch/arm/lib/_ashrdi3.S
index 4d93c8a..c74fd64 100644
--- a/arch/arm/lib/_ashrdi3.S
+++ b/arch/arm/lib/_ashrdi3.S
@@ -4,6 +4,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include linux/linkage.h
+
 #ifdef __ARMEB__
 #define al r1
 #define ah r0
@@ -13,9 +15,8 @@
 #endif
 
 .globl __ashrdi3
-.globl __aeabi_lasr
 __ashrdi3:
-__aeabi_lasr:
+ENTRY(__aeabi_lasr)
 
subsr3, r2, #32
rsb ip, r2, #32
@@ -24,3 +25,4 @@ __aeabi_lasr:
orrmi   al, al, ah, lsl ip
mov ah, ah, asr r2
mov pc, lr
+ENDPROC(__aeabi_lasr)
diff --git a/arch/arm/lib/_divsi3.S b/arch/arm/lib/_divsi3.S
index 6015493..c463c68 100644
--- a/arch/arm/lib/_divsi3.S
+++ b/arch/arm/lib/_divsi3.S
@@ -1,3 +1,5 @@
+#include linux/linkage.h
+
 .macro ARM_DIV_BODY dividend, divisor, result, curbit
 
 #if __LINUX_ARM_ARCH__ = 5
@@ -95,9 +97,8 @@
 
.align  5
 .globl __divsi3
-.globl __aeabi_idiv
 __divsi3:
-__aeabi_idiv:
+ENTRY(__aeabi_idiv)
cmp r1, #0
eor ip, r0, r1  @ save the sign of the result.
beq Ldiv0
@@ -139,3 +140,4 @@ Ldiv0:
bl  __div0
mov r0, #0  @ About as wrong as it could be.
ldr pc, [sp], #4
+ENDPROC(__aeabi_idiv)
diff --git a/arch/arm/lib/_lshrdi3.S b/arch/arm/lib/_lshrdi3.S
index 33296a0..1f9b916 100644
--- a/arch/arm/lib/_lshrdi3.S
+++ b/arch/arm/lib/_lshrdi3.S
@@ -4,6 +4,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include linux/linkage.h
+
 #ifdef __ARMEB__
 #define al r1
 #define ah r0
@@ -13,9 +15,8 @@
 #endif
 
 .globl __lshrdi3
-.globl __aeabi_llsr
 __lshrdi3:
-__aeabi_llsr:
+ENTRY(__aeabi_llsr)
 
subsr3, r2, #32
rsb ip, r2, #32
@@ -24,3 +25,4 @@ __aeabi_llsr:
orrmi   al, al, ah, lsl ip
mov ah, ah, lsr r2
mov pc, lr
+ENDPROC(__aeabi_llsr)
diff --git a/arch/arm/lib/_modsi3.S b/arch/arm/lib/_modsi3.S
index 3d31a55..c5e1c22 100644
--- a/arch/arm/lib/_modsi3.S
+++ b/arch/arm/lib/_modsi3.S
@@ -1,3 +1,5 @@
+#include linux/linkage.h
+
 .macro ARM_MOD_BODY dividend, divisor, order, spare
 
 #if __LINUX_ARM_ARCH__ = 5
@@ -69,8 +71,7 @@
 .endm
 
.align  5
-.globl __modsi3
-__modsi3:
+ENTRY(__modsi3)
cmp r1, #0
beq Ldiv0
rsbmi   r1, r1, #0  @ loops below use unsigned.
@@ -88,7 +89,7 @@ __modsi3:
 10:cmp ip, #0
rsbmi   r0, r0, #0
mov pc, lr
-
+ENDPROC(__modsi3)
 
 Ldiv0:
 
diff --git a/arch/arm/lib/_udivsi3.S b/arch/arm/lib/_udivsi3.S
index 1309802..3b653be 100644
--- a/arch/arm/lib/_udivsi3.S
+++ b/arch/arm/lib/_udivsi3.S
@@ -1,3 +1,5 @@
+#include linux/linkage.h
+
 /* # 1 libgcc1.S */
 @ libgcc1 routines for ARM cpu.
 @ Division routines, written by Richard Earnshaw, (rearn...@armltd.co.uk)
@@ -72,8 +74,7 @@ Ldiv0:
ldmia   sp!, {pc}
.size  __udivsi3   , . -  __udivsi3
 
-.globl __aeabi_uidivmod
-__aeabi_uidivmod:
+ENTRY(__aeabi_uidivmod)
 
stmfd   sp!, {r0, r1, ip, lr}
bl  __aeabi_uidiv
@@ -81,9 +82,9 @@ __aeabi_uidivmod:
mul r3, r0, r2
sub r1, r1, r3
mov pc, lr
+ENDPROC(__aeabi_uidivmod)
 
-.globl __aeabi_idivmod
-__aeabi_idivmod:
+ENTRY(__aeabi_idivmod)
 
stmfd   sp!, {r0, r1, ip, lr}
bl  __aeabi_idiv
@@ -91,3 +92,4 @@ __aeabi_idivmod:
mul r3, r0, r2
sub r1, r1, r3
mov pc, lr
+ENDPROC(__aeabi_idivmod)
diff --git a/arch/arm/lib/_umodsi3.S b/arch/arm/lib/_umodsi3.S
index 8465ef0..b166737 100644
--- a/arch/arm/lib/_umodsi3.S
+++ b/arch/arm/lib/_umodsi3.S
@@ -1,3 +1,5 @@
+#include linux/linkage.h
+
 /* # 1 libgcc1.S */
 @ libgcc1 routines 

[U-Boot] [PATCH 2/2] Revert break build if it would produce broken binary

[Simon Glass]

The root cause of this problem should now be fixed.

This reverts commit a6a4c542d316b3401f0840ac5378743191bca851.
Signed-off-by: Simon Glass s...@chromium.org
---

 arch/arm/include/asm/u-boot.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
index ae4c21b..43cc494 100644
--- a/arch/arm/include/asm/u-boot.h
+++ b/arch/arm/include/asm/u-boot.h
@@ -49,8 +49,4 @@ typedef struct bd_info {
 #define IH_ARCH_DEFAULT IH_ARCH_ARM64
 #endif
 
-#if defined(CONFIG_USE_PRIVATE_LIBGCC)  defined(CONFIG_SYS_THUMB_BUILD)
-#error Thumb build does not work with private libgcc.
-#endif
-
 #endif /* _U_BOOT_H_ */
-- 
2.2.0.rc0.207.ga3a616c

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

Re: [U-Boot] [patch] break build if it would produce broken binary

[Simon Glass]

Hi,

On 13 April 2015 at 14:38, Pavel Machek pa...@denx.de wrote:

 On Mon 2015-04-13 08:52:52, Tom Rini wrote:
  On Mon, Apr 13, 2015 at 02:49:28PM +0200, Pavel Machek wrote:
 
   Add an error in known-bad case so that we don't produce broken and
   hard to debug binaries.
  
   Signed-off-by: Pavel Machek pa...@denx.de
  
   diff --git a/arch/arm/include/asm/u-boot.h b/arch/arm/include/asm/u-boot.h
   index 43cc494..ae4c21b 100644
   --- a/arch/arm/include/asm/u-boot.h
   +++ b/arch/arm/include/asm/u-boot.h
   @@ -49,4 +49,8 @@ typedef struct bd_info {
#define IH_ARCH_DEFAULT IH_ARCH_ARM64
#endif
  
   +#if defined(CONFIG_USE_PRIVATE_LIBGCC)  defined(CONFIG_SYS_THUMB_BUILD)
   +#error Thumb build does not work with private libgcc.
   +#endif
   +
#endif /* _U_BOOT_H_ */
 
  I'm agreeable to taking this for the release if you'll go and debug
  what's wrong with our private libgcc code for the next release.

 If you are willing to ship u-boot with known and nasty to debug
 problem, it is your choice.

 Either the patch is good or it is bad, my future plans should have
 nothing to do with it. Notice that this patch does not help _me_ in
 any way, as I know about the issue and am unlikely to hit it again,
 and that original problem still breaks the build on my system.

 Help from someone knowing ARM assembly would be nice. Now that we know
 what the problem is, it should not be too bad.

I hit this also and I think it has to do with missing ENTRY/ENDPROC
macros. I sent a patch.

Pavel, your email seemed to me as a little sharp for the mailing list.


 Best regards,
 Pavel

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] Revert break build if it would produce broken binary

[Tom Rini]

On Tue, Jun 02, 2015 at 11:08:21AM -0600, Simon Glass wrote:

 The root cause of this problem should now be fixed.
 
 This reverts commit a6a4c542d316b3401f0840ac5378743191bca851.
 Signed-off-by: Simon Glass s...@chromium.org

Thanks for digging into all of this!  Pavel, can you confirm that with
these two applied things work still?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] omap_gpmc: move prefetch out of CONFIG_NAND_OMAP_ELM

[Tom Rini]

On Sat, May 30, 2015 at 10:11:23AM +0200, Jeroen Hofstee wrote:

 The prefech mode is a feature of the gpmc, not the ELM. An am3517
 does not have an elm, but can do prefeches, so move the code out
 of the CONFIG_NAND_OMAP_ELM ifdef.
 
 Cc: Scott Wood scottw...@freescale.com
 Cc: Tom Rini tr...@konsulko.com
 Cc: Daniel Mack zon...@gmail.com
 
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl

Reviewed-by: Tom Rini tr...@konsulko.com

-- 
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 2/3] mtd: OMAP: Enable GPMC prefetch mode for 16 bit access

[Tom Rini]

On Sat, May 30, 2015 at 10:11:24AM +0200, Jeroen Hofstee wrote:

 commit c316f57 mtd: OMAP: Enable GPMC prefetch mode only enabled
 prefetch mode for 8 bit nand access, this adds 16 bit as well.
 
 Cc: Scott Wood scottw...@freescale.com
 Cc: Tom Rini tr...@konsulko.com
 Cc: Daniel Mack zon...@gmail.com
 
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl

Reviewed-by: Tom Rini tr...@konsulko.com

-- 
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 3/3] boards: tam3517-common: enable gpmc prefetch mode

[Tom Rini]

On Sat, May 30, 2015 at 10:11:25AM +0200, Jeroen Hofstee wrote:

 Since the tam3517 base board has a 16bit wide nand connected to
 the gpmc, enable the prefetch mode, since that is now supported.
 
 Cc: Scott Wood scottw...@freescale.com
 Cc: Tom Rini tr...@konsulko.com
 Cc: pekon gupta pe...@ti.com
 Cc: Nishanth Menon n...@ti.com
 Cc: Daniel Mack zon...@gmail.com
 Cc: Tapani Utriainen tap...@technexion.com
 
 Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl

Reviewed-by: Tom Rini tr...@konsulko.com

-- 
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 2/2] nand: sunxi: Add support for booting from internal NAND memory

[Roy Spliet]

Dear Scott,

Thank you for taking your time to feedback. However, it seems to be 
about a week and two versions of the patchset too late. Most of your 
issues have been addressed in the meanwhile, as you can see in Hans de 
Goede's sunxi branch.

Yours,

Roy

Op 02-06-15 om 00:14 schreef Scott Wood:

On Thu, 2015-05-21 at 15:59 +0200, Roy Spliet wrote:

+#ifdef CONFIG_NAND_SUNXI
+#include nand.h
+#endif

Why do you need the ifdef?

+#include common.h

+#include config.h
+#include asm/io.h
+#include nand.h
+
+/* DMAC */
+#define DMAC_BASE0x01c02000
+#define DMAC_REG(a)  (DMAC_BASE + a)
+
+#define DMAC_INT DMAC_REG(0x000)
+#define DMAC_DDMA_CFGDMAC_REG(0x300)
+#define DMAC_DDMA_SRCDMAC_REG(0x304)
+#define DMAC_DDMA_DSTDMAC_REG(0x308)
+#define DMAC_DDMA_BYTE_COUNT DMAC_REG(0x30C)
+#define DMAC_DDMA_PARAM  DMAC_REG(0x318)
+
+/* NAND controller */
+#define NANDFLASHC_BASE  0x01c03000
+#define NREG(a)  (0x01c03000 + a)
+
+#define NANDFLASHC_CTL   NREG(0x00)
+#define NANDFLASHC_CTL_EN0x0001
+#define NANDFLASHC_CTL_RST   0x0002
+#define NANDFLASHC_CTL_RAM_METHOD0x4000
+
+#define NANDFLASHC_STNREG(0x004)
+#define NANDFLASHC_INT   NREG(0x008)
+#define NANDFLASHC_TIMING_CTLNREG(0x00C)
+#define NANDFLASHC_TIMING_CFGNREG(0x010)
+#define NANDFLASHC_ADDR_LOW  NREG(0x014)
+#define NANDFLASHC_ADDR_HIGH NREG(0x018)
+#define NANDFLASHC_SECTOR_NUMNREG(0x01C)
+#define NANDFLASHC_CNT   NREG(0x020)
+
+#define NANDFLASHC_CMD   NREG(0x024)
+#define NANDFLASHC_SEND_CMD1 (1  22)
+#define NANDFLASHC_WAIT_FLAG (1  23)
+
+#define NANDFLASHC_RCMD_SET  NREG(0x028)
+#define NANDFLASHC_WCMD_SET  NREG(0x02C)
+#define NANDFLASHC_IO_DATA   NREG(0x030)
+#define NANDFLASHC_ECC_CTL   NREG(0x034)
+#define NANDFLASHC_ECC_STNREG(0x038)
+#define NANDFLASHC_DEBUG NREG(0x03c)
+#define NANDFLASHC_ECC_CNT0  NREG(0x040)
+#define NANDFLASHC_ECC_CNT1  NREG(0x044)
+#define NANDFLASHC_ECC_CNT2  NREG(0x048)
+#define NANDFLASHC_ECC_CNT3  NREG(0x04c)
+#define NANDFLASHC_USER_DATA_BASENREG(0x050)
+#define NANDFLASHC_EFNAND_STATUS NREG(0x090)
+#define NANDFLASHC_SPARE_AREANREG(0x0A0)
+#define NANDFLASHC_PATTERN_IDNREG(0x0A4)
+#define NANDFLASHC_RAM0_BASE NREG(0x400)
+#define NANDFLASHC_RAM1_BASE NREG(0x800)

Shouldn't these be in a header file so they can be shared with a non-
SPL driver?


+void
+nand_init(void)
+{

Don't put a newline after the return type.


+ uint32_t val;
+
+ board_nand_init();
+ val = readl(NANDFLASHC_CTL);
+ val |= NANDFLASHC_CTL_RST;
+ writel(val, NANDFLASHC_CTL);
+
+ /* Wait until reset pin is deasserted */
+ do {
+ val = readl(NANDFLASHC_CTL);
+ if (!(val  NANDFLASHC_CTL_RST))
+ break;
+ } while (1);

Add a timeout to delay loops.


+
+ /** \todo Chip select, currently kind of static */
+ val = readl(NANDFLASHC_CTL);
+ val = 0xf0fff0f2;

Don't put magic numbers in the code -- use symbolic constants taht
describe what the fields mean.

+/* random seed */

+static const uint16_t random_seed[128] = {
+ 0x2b75, 0x0bd0, 0x5ca3, 0x62d1, 0x1c93, 0x07e9, 0x2162, 0x3a72,
+ 0x0d67, 0x67f9, 0x1be7, 0x077d, 0x032f, 0x0dac, 0x2716, 0x2436,
+ 0x7922, 0x1510, 0x3860, 0x5287, 0x480f, 0x4252, 0x1789, 0x5a2d,
+ 0x2a49, 0x5e10, 0x437f, 0x4b4e, 0x2f45, 0x216e, 0x5cb7, 0x7130,
+ 0x2a3f, 0x60e4, 0x4dc9, 0x0ef0, 0x0f52, 0x1bb9, 0x6211, 0x7a56,
+ 0x226d, 0x4ea7, 0x6f36, 0x3692, 0x38bf, 0x0c62, 0x05eb, 0x4c55,
+ 0x60f4, 0x728c, 0x3b6f, 0x2037, 0x7f69, 0x0936, 0x651a, 0x4ceb,
+ 0x6218, 0x79f3, 0x383f, 0x18d9, 0x4f05, 0x5c82, 0x2912, 0x6f17,
+ 0x6856, 0x5938, 0x1007, 0x61ab, 0x3e7f, 0x57c2, 0x542f, 0x4f62,
+ 0x7454, 0x2eac, 0x7739, 0x42d4, 0x2f90, 0x435a, 0x2e52, 0x2064,
+ 0x637c, 0x66ad, 0x2c90, 0x0bad, 0x759c, 0x0029, 0x0986, 0x7126,
+ 0x1ca7, 0x1605, 0x386a, 0x27f5, 0x1380, 0x6d75, 0x24c3, 0x0f8e,
+ 0x2b7a, 0x1418, 0x1fd1, 0x7dc1, 0x2d8e, 0x43af, 0x2267, 0x7da3,
+ 0x4e3d, 0x1338, 0x50db, 0x454d, 0x764d, 0x40a3, 0x42e6, 0x262b,
+ 0x2d2e, 0x1aea, 0x2e17, 0x173d, 0x3a6e, 0x71bf, 0x25f9, 0x0a5d,
+ 0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
+};

Why is randomness needed?


+uint32_t ecc_errors = 0;

Why is this global?


+int
+nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
+{
+ dma_addr_t dst_block;
+ dma_addr_t dst_end;
+ phys_addr_t addr = offs;
+
+ dst_end = ((dma_addr_t) dest) + size;
+
+ 

Re: [U-Boot] cpsw not working with slave2 port defined only

[Belisko Marek]

Hi Mugunthan,

On Mon, Jun 1, 2015 at 11:10 AM, Mugunthan V N mugunthan...@ti.com wrote:
 On Tuesday 26 May 2015 01:00 AM, Belisko Marek wrote:
 Hi,

 I have custom am33xx board with phy connected to slave2 port. I
 copy'n'paste cpsw setup from /board/BuR/common/common.c but I'm using
 only slave2 port (RMII mode) so my cpsw_slave_data looks like:

 static struct cpsw_slave_data cpsw_slaves[] = {
 {
  .slave_reg_ofs  = 0x308,
  .sliver_reg_ofs = 0xdc0,
  .phy_addr   = 4,
 },
 };

 with this configuration cpsw driver can detect link but it cannot
 establish any communication (tested with dhcp command). When I add to
 cpsw_slaves dummy slave1 port definition (with e.g. phy_addr = 0) it
 start working.

 mdio bus is working fine (tested with mdio list + mdio read). Pinmux
 is good as it works with dummy slave1 config. Any ideas what I'm doing
 wrong or why only slave2 port cannot be used? I grep whole source code
 but all boards using cpsw use slave1 only or slave1/slave2
 configurations. Many thanks.


 Do not remove slave 0 structures and have no of slaves as 2 and set
 active slave to 1 as done in the following commit
 4c8014b9429b593c28fbf0384a6c7ded8587806a in mainline u-boot.
Thanks it works now. I picked 7a0227534dfc17c96bb02529fb69971d079a85f0
and setup everything
as you suggested and it works fine.

 The driver uses the slave numbers to add mac address to ALE, which will
 fail when you remove slaves from the salve structures.
I think this should be fixed to avoid problems when you have only
slave2. When I have time I'll look on it.

 Regards
 Mugunthan V N

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot