[U-Boot] [LONG] Re: [PATCH v3 0/6] Optimize ARM relocation
On Tue, 18 Jun 2013 16:54:57 +0200, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Jeroen, On Sun, 16 Jun 2013 15:33:32 +0200, Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Albert, On 06/13/2013 08:54 PM, Jeroen Hofstee wrote: binaries only use one type of relocation record, R_ARM_RELATIVE., then optimizing relocation code accordingly. fyi, I had a look at the clang build and it doesn't boot after these patches... When constant pointers are used without fpie, e.g. the arguments to printf, gcc will load the address with ldr / R_ARM_ABS32, clang sets the address with a movw / movt pair. Hmm... Why do you remove -fpie from the gcc build? ld -r will make the former relative, but the movw / movt cannot be fixed. So I set fpie for clang, which generates a couple of R_ARM_ABS32: Most notably a reference to do_bootd. Since it is no longer valid after this patch and used in command.c this crashes the board (unless there happens to be a valid address in it). gcc seems to always recalculate it using pc. Another symbol is _start, but that looks easily fixable. The last one looks similar like the do_bootd and I haven't bothered to check the details. Can you give more precise info on the issue? Such as the U-Boot codebase (even if not in shape for submitting) and clang compiler version you are using, so that I can try the build on my side and have a look at how/why r_arm_abs32 relocation recodes are generated and how to avoid it? Update: After some IRC discussion with Jeroen, we've been able to pinpoint an issue when building armv7 (and possibly others) with optimization level -O2 instead of -Os (OPTFLAGS in ./config.mk). NOTE: -O2 is not the optimization level defined by default, and default builds do not exhibit any issue. Specifically, building the twister target with -O2 results in the build failing with this error message: arm-linux-gnueabi-ld.bfd: arch/arm/cpu/armv7/omap3/libomap3.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC. Compiler option -fPIC was replaced with linker option -pie when switching from GOT to ELF relocation tables in commit 92d5ecba. Adding -fPIE (rather than -fPIC as we are linking an executable) results in the build succeeding again, but with a few R_ARM_ABS32 relocations creeping back in. Analysis of the absolute relocations show that their causes are: 1. use of 'ldr r0, =_start' instead of 'adr r0,_start' in arch/arm/cpu/armv7/start.S (twice) -- actually, ldr refers to the link-time _start, which may be right or wrong, whereas adr refers to the run-time _start, which is always correct. 2. use of 'ldr r0, =_start' instead of 'adr r0,_start' in arch/arm/lib/relocate.S. Same remark as above. 3. Declaration EXPORT_FUNC(do_reset) in include/_exports.h. That is the only 'do_xxx' exported function, and I suspect there is no actual need for exporting it. Incidentally, the U_BOOT_CMD() statement is in common/cmd_boot.c while the do_reset function is in arch/arm/lib/reset -- that's surprising, although I understand why we might not want a common/do_reset.c file with only the U_BOOT_CMD() statement. 4. There is an explicit comparision between a function pointer and do_bootd for recursion detection reasons. While I am not sure why there is a recursion issue, I am sure however that we could test for recursion by turning the 'repeatable' field in cmd_tbl_s into a 'flags' field with bit 0 set for 'repeatable' and bit 1 set when command is 'do_bootd', thereby removing the test for the do_bootd address. Even though -O2 (plus -fPIE) is not currently used in U-boot, and even though it reduces the relocation table size, I don't intend to switch to it because this increases the code and data size -- for twister, global increase is 4.5% for u-boot and 15.5% for SPL. Nevertheless, I think we should fix the issues above, if only because they are indicative of potential trouble, so I'll send out a patch for this; but it'll be based over the relocation optimization patches to avoid merge conflicts. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merge Window close date
Hi Masahiro,
On Wed, 19 Jun 2013 10:54:27 +0900, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
How strict is the MW rule in U-Boot development?
I can't say for sure because I'm quite new here,
but the development looks (at least to me)
to keep going regardless of the MW status.
To sum up things (anyone correct me as needed):
- patches submitted within the merge window will be included in the
upcoming release ('master' branch); patches submitted outside the
merge window are scheduled for the release after ('next' branch).
- if V1 of a patch has initially been submitted during the merge window,
then subsequent versions (V2, V3...) can be submitted after the merge
window is closed, and will still be considered for inclusion in the
upcoming (master branch) release.
- if a bugfix patch is submitted outside the merge window, it will be
included in the upcoming (master branch) release.
- at the custodians' discretion, a non-bugfix patch submitted outside
the merge window might still end in the upcoming release depending
on its importance and impact.
- the nearer the release day, the lesser the chances that a patch
submitted outside the merge window gets applied -- IOW, patches
accepted between the last -rc and the release will only be critical
bugfixes with a very controlled impact.
Therefore, you may see patches being submitted, discussed and applied
at any time, within or outside the merge window; the only difference
being xhich branch the patch goes to when/if applied.
Best Regards
Masahiro Yamada
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merge Window close date
Dear Masahiro Yamada, In message 20130619105426.7444.aa925...@jp.panasonic.com you wrote: Especailly after reading this http://thread.gmane.org/gmane.linux.network/104943/focus=104951 Maybe I became a little nervous about the MW. I'm not sure what you mean here? Let me ask one more question. How strict is the MW rule in U-Boot development? Pretty strict, but we are no fanatics. If your patch is clearly local only (say, affecting definitely only your own board), then we may bend the rules a bit. Massiveglobal changes are a strict no, no, though. I can't say for sure because I'm quite new here, but the development looks (at least to me) to keep going regardless of the MW status. Of course development goes on continuously. But patches willnot be accepted into the current mainline tree until the net MW opens. Often there will be next trees or similar in the respective custodians repositories. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Premature optimization is the root of all evil. -- D.E. Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [[PATCH]] imx6: fix GPR2 wrong definition
Signed-off-by: Pierre Aubert p.aub...@staubli.com
CC: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/arch-mx6/imx-regs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index 03abb2a..45824f9 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -364,7 +364,7 @@ struct iomuxc {
#define IOMUXC_GPR2_MODE_DISABLED 0
#define IOMUXC_GPR2_MODE_ENABLED_DI0 1
-#define IOMUXC_GPR2_MODE_ENABLED_DI1 2
+#define IOMUXC_GPR2_MODE_ENABLED_DI1 3
#define IOMUXC_GPR2_LVDS_CH1_MODE_OFFSET 2
#define IOMUXC_GPR2_LVDS_CH1_MODE_MASK
(3IOMUXC_GPR2_LVDS_CH1_MODE_OFFSET)
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 02/14] sf: Discover the bank addr commands
On Wed, Jun 19, 2013 at 9:58 AM, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On Thu, Jun 13, 2013 at 1:55 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Bank/Extended addr commands are specific to particular
flash vendor so discover them based on the idocode0.
Assign the discovered bank commands to spi_flash members
so-that the bank read/write will use their specific operations.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
Changes for v4:
- none
Changes for v3:
- none
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 21 +
drivers/mtd/spi/spi_flash_internal.h | 14 ++
include/spi_flash.h | 2 ++
3 files changed, 37 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9ddd070..9c90f00 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -304,6 +304,27 @@ int spi_flash_cmd_bankaddr_write(struct spi_flash
*flash, u8 bank_sel)
return 0;
}
+int spi_flash_bank_config(struct spi_flash *flash, u8 idcode0)
+{
+ /* discover bank cmds */
+ switch (idcode0) {
+ case SPI_FLASH_SPANSION_IDCODE0:
+ flash-bank_cmd[0] = CMD_BANKADDR_BRRD;
+ flash-bank_cmd[1] = CMD_BANKADDR_BRWR;
I suggest bank_read_cmd, bank_write_cmd
Thought of same, later tried with array.
OK will make this change.
--
Thanks,
Jagan.
+ break;
+ case SPI_FLASH_STMICRO_IDCODE0:
+ case SPI_FLASH_WINBOND_IDCODE0:
+ flash-bank_cmd[0] = CMD_EXTNADDR_RDEAR;
+ flash-bank_cmd[1] = CMD_EXTNADDR_WREAR;
+ break;
+ default:
+ printf(SF: Unsupported bank commands %02x\n, idcode0);
+ return -1;
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_OF_CONTROL
int spi_flash_decode_fdt(const void *blob, struct spi_flash *flash)
{
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 772fef6..db6c444 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -28,6 +28,17 @@
#define CMD_ERASE_64K 0xd8
#define CMD_ERASE_CHIP 0xc7
+/* Manufacture ID's */
+#define SPI_FLASH_SPANSION_IDCODE0 0x01
+#define SPI_FLASH_STMICRO_IDCODE0 0x20
+#define SPI_FLASH_WINBOND_IDCODE0 0xef
+
+/* Bank addr access commands */
+#define CMD_BANKADDR_BRWR 0x17
+#define CMD_BANKADDR_BRRD 0x16
+#define CMD_EXTNADDR_WREAR 0xC5
+#define CMD_EXTNADDR_RDEAR 0xC8
+
/* Common status */
#define STATUS_WIP 0x01
@@ -80,6 +91,9 @@ int spi_flash_cmd_write_status(struct spi_flash *flash,
u8 sr);
/* Program the bank address register */
int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel);
+/* Configure the BAR - discover the bank cmds */
+int spi_flash_bank_config(struct spi_flash *flash, u8 idcode0);
+
/*
* Same as spi_flash_cmd_read() except it also claims/releases the SPI
* bus. Used as common part of the -read() operation.
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3b6a44e..50a03bf 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -38,6 +38,8 @@ struct spi_flash {
u32 page_size;
/* Erase (sector) size */
u32 sector_size;
+ /* Bank cmds - cmd[0] - read, cmd[1] - write */
+ u8 bank_cmd[2];
void *memory_map; /* Address of read-only SPI flash access */
int (*read)(struct spi_flash *flash, u32 offset,
--
1.8.3
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 14/14] sf: Add Flag status register polling support
On Wed, Jun 19, 2013 at 10:00 AM, Simon Glass s...@chromium.org wrote:
Hi Jagan,
On Thu, Jun 13, 2013 at 1:55 PM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Flag status register polling is required for micron 512Mb flash
devices onwards, for performing erase/program operations.
Like polling for WIP(Write-In-Progress) bit in read status register,
spi_flash_cmd_wait_ready will poll for PEC(Program-Erase-Control)
bit in flag status register.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
Reviewed-by: Simon Glass s...@chromium.org
---
Changes for v4:
- Remove STMICRO config, discover poll_cmd at probe
Changes for v3:
- none
Changes for v2:
- none
drivers/mtd/spi/spi_flash.c | 21 +
drivers/mtd/spi/spi_flash_internal.h | 2 ++
include/spi_flash.h | 3 +++
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index e5b401f..c439601 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -200,12 +200,19 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
unsigned long timebase;
int ret;
u8 status;
+ u8 check_status = 0x0;
u8 poll_bit = STATUS_WIP;
- u8 cmd = CMD_READ_STATUS;
+ u8 cmd = flash-poll_cmd;
+
+ if (cmd == CMD_FLAG_STATUS) {
+ poll_bit = STATUS_PEC;
+ check_status = poll_bit;
+ }
ret = spi_xfer(spi, 8, cmd, NULL, SPI_XFER_BEGIN);
if (ret) {
- debug(SF: Failed to send command %02x: %d\n, cmd, ret);
+ debug(SF: fail to read %s status register\n,
+ cmd == CMD_READ_STATUS ? read : flag);
return ret;
}
@@ -217,14 +224,14 @@ int spi_flash_cmd_wait_ready(struct spi_flash
*flash, unsigned long timeout)
if (ret)
return -1;
- if ((status poll_bit) == 0)
+ if ((status poll_bit) == check_status)
break;
} while (get_timer(timebase) timeout);
spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
- if ((status poll_bit) == 0)
+ if ((status poll_bit) == check_status)
return 0;
/* Timed out */
@@ -542,6 +549,12 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
goto err_manufacturer_probe;
#endif
+ /* Discover the poll_cmd, as STMICRO is something different */
+ flash-poll_cmd = CMD_READ_STATUS;
Move this line into spi_flash_do_alloc()
+ if ((*idp == SPI_FLASH_STMICRO_IDCODE0)
+ (flash-size = 0x400))
+ flash-poll_cmd = CMD_FLAG_STATUS;
...and the above into the stmicro.c's probe handler
Sound reasonable-
Will do it.
--
Thanks,
Jagan.
+
#ifdef CONFIG_OF_CONTROL
if (spi_flash_decode_fdt(gd-fdt_blob, flash)) {
debug(SF: FDT decode error\n);
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index e9b85bf..8147f27 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
#define CMD_PAGE_PROGRAM 0x02
#define CMD_WRITE_DISABLE 0x04
#define CMD_READ_STATUS0x05
+#define CMD_FLAG_STATUS0x70
#define CMD_WRITE_ENABLE 0x06
#define CMD_ERASE_4K 0x20
#define CMD_ERASE_32K 0x52
@@ -45,6 +46,7 @@
/* Common status */
#define STATUS_WIP 0x01
+#define STATUS_PEC 0x80
/* Send a single-byte command to the device and read the response */
int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t
len);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 1de193a..e94e59c 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -44,6 +44,9 @@ struct spi_flash {
/* Current flash bank */
u8 bank_curr;
#endif
+ /* Poll cmd - for flash erase/program */
+ u8 poll_cmd;
+
void *memory_map; /* Address of read-only SPI flash access */
int (*read)(struct spi_flash *flash, u32 offset,
size_t len, void *buf);
--
1.8.3
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sf: Unify spi_flash write code
On Wed, Jun 19, 2013 at 10:01 AM, Simon Glass s...@chromium.org wrote: Hi Jagan, On Fri, Jun 14, 2013 at 1:18 PM, Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com wrote: Move common flash write code into spi_flash_write_common(). Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com --- drivers/mtd/spi/spi_flash.c | 122 --- drivers/mtd/spi/spi_flash_internal.h | 6 ++ 2 files changed, 60 insertions(+), 68 deletions(-) This looks good except that spi_flash_write_common() is not a great name - only one of the operations is a 'write'. Perhaps spi_flash_oper_common() or similar? I think it's ok to use spi_flash_write_common(). because, I put this name as the write sequence has all theseopers write_enable, write and wait_ready, not by taking only write operation. May be I will try to put spi_flash_write_oper_common() Any comments.?? Thanks, Jagan. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] Add TI816X evm board support
Signed-off-by: Antoine Tenart aten...@adeneo-embedded.com
---
MAINTAINERS |4 +
board/ti/ti816x/Makefile | 47
board/ti/ti816x/evm.c| 249 ++
boards.cfg |1 +
include/configs/ti816x_evm.h | 188 +++
5 files changed, 489 insertions(+)
create mode 100644 board/ti/ti816x/Makefile
create mode 100644 board/ti/ti816x/evm.c
create mode 100644 include/configs/ti816x_evm.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7820375..38ff5c3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -940,6 +940,10 @@ Lucas Stach d...@lynxeye.de
colibri_t20_irisTegra20 (ARM7 A9 Dual Core)
+Antoine Tenart aten...@adeneo-embedded.com
+
+ TI816X ARM ARMV7 (TI816x Soc)
+
Nick Thompson nick.thomp...@gefanuc.com
da830evmARM926EJS (DA830/OMAP-L137)
diff --git a/board/ti/ti816x/Makefile b/board/ti/ti816x/Makefile
new file mode 100644
index 000..dc23d93
--- /dev/null
+++ b/board/ti/ti816x/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2013, Adeneo Embedded www.adeneo-embedded.com
+# Antoine Tenart, aten...@adeneo-embedded.com
+#
+# Based on TI-PSP-04.00.02.14 :
+#
+# Copyright (C) 2009, Texas Instruments, Incorporated
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program 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 version 2.
+#
+# This program is distributed as is WITHOUT ANY WARRANTY of any
+# kind, whether express or implied; without even the implied warranty
+# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := evm.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+clean:
+ rm -f $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
new file mode 100644
index 000..12e98d5
--- /dev/null
+++ b/board/ti/ti816x/evm.c
@@ -0,0 +1,249 @@
+/*
+ * evm.c
+ *
+ * Copyright (C) 2013, Adeneo Embedded www.adeneo-embedded.com
+ * Antoine Tenart, aten...@adeneo-embedded.com
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+#include common.h
+#include spl.h
+#include asm/cache.h
+#include asm/io.h
+#include asm/arch/clock.h
+#include asm/arch/cpu.h
+#include asm/arch/ddr_defs.h
+#include asm/arch/hardware.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mmc_host_def.h
+#include asm/arch/mem.h
+#include asm/arch/mux.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ gd-bd-bi_boot_params = PHYS_DRAM_1 + 0x100;
+ return 0;
+}
+
+#if defined(CONFIG_SPL_BUILD)
+
+static struct module_pin_mux mmc_pin_mux[] = {
+ { OFFSET(pincntl157), PULLDOWN_EN | PULLUDDIS | MODE(0x0) },
+ { OFFSET(pincntl158), PULLDOWN_EN | PULLUDEN | MODE(0x0) },
+ { OFFSET(pincntl159), PULLUP_EN | PULLUDDIS | MODE(0x0) },
+ { OFFSET(pincntl160), PULLUP_EN | PULLUDDIS | MODE(0x0) },
+ { OFFSET(pincntl161), PULLUP_EN | PULLUDDIS | MODE(0x0) },
+ { OFFSET(pincntl162), PULLUP_EN | PULLUDDIS | MODE(0x0) },
+ { OFFSET(pincntl163), PULLUP_EN | PULLUDDIS | MODE(0x0) },
+ { -1 },
+};
+
+const struct dmm_lisa_map_regs evm_lisa_map_regs = {
+ .dmm_lisa_map_0 = 0x,
+ .dmm_lisa_map_1 = 0x,
+ .dmm_lisa_map_2 = 0x80640300,
+ .dmm_lisa_map_3 = 0xC0640320,
+};
+
+/*
+ * DDR2 related definitions
+ */
+
+static struct ddr_data ddr2_data = {
+ .datardsratio0 = ((0x4010) | (0x400)),
+ .datawdsratio0 = ((0x4A10) | (0x4A0)),
+ .datawiratio0 = ((0x010) | (0x00)),
+ .datagiratio0 = ((0x010) | (0x00)),
+ .datafwsratio0 = ((0x13A10) | (0x13A0)),
+ .datawrsratio0 = ((0x8A10) | (0x8A0)),
+ .datauserank0delay = 0x1,
+ .datadldiff0= 0x0, /* depend on cpu rev, set later */
+};
+
+static struct cmd_control ddr2_ctrl = {
+ .cmd0csratio= 0x80,
+ .cmd0dldiff = 0x04, /* reset value is 0x4 */
+ .cmd0iclkout= 0x00,
+
+ .cmd1csratio= 0x80,
+ .cmd1dldiff = 0x04,
+ .cmd1iclkout= 0x00,
+
+ .cmd2csratio= 0x80,
+ .cmd2dldiff = 0x04,
+ .cmd2iclkout= 0x00,
+
+};
+
+static
[U-Boot] [PATCH v4 1/3] Prepare for TI816X : reuse existing code from TI814X
Rename some CONFIG_TI814X to a more generic CONFIG_81XX Signed-off-by: Antoine Tenart aten...@adeneo-embedded.com --- Makefile|2 +- arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/omap-common/Makefile |2 +- arch/arm/include/asm/arch-am33xx/cpu.h |2 +- arch/arm/include/asm/arch-am33xx/omap.h |2 +- drivers/serial/ns16550.c|4 ++-- spl/Makefile|2 +- 7 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 693b3f2..248b1f4 100644 --- a/Makefile +++ b/Makefile @@ -337,7 +337,7 @@ LIBS-y += api/libapi.o LIBS-y += post/libpost.o LIBS-y += test/libtest.o -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI81XX),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index 7a8c2d0..415ace8 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -32,7 +32,7 @@ COBJS += cache_v7.o COBJS += cpu.o COBJS += syslib.o -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI814X),) +ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI81XX),) SOBJS += lowlevel_init.o endif diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index c4b9809..20586d3 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -37,7 +37,7 @@ COBJS += vc.o COBJS += abb.o endif -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI81XX),) COBJS += boot-common.o SOBJS += lowlevel_init.o endif diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h b/arch/arm/include/asm/arch-am33xx/cpu.h index 3d3a7c8..13c0667 100644 --- a/arch/arm/include/asm/arch-am33xx/cpu.h +++ b/arch/arm/include/asm/arch-am33xx/cpu.h @@ -54,7 +54,7 @@ /* Reset control */ #ifdef CONFIG_AM33XX #define PRM_RSTCTRL(PRCM_BASE + 0x0F00) -#elif defined(CONFIG_TI814X) +#elif defined(CONFIG_TI81XX) #define PRM_RSTCTRL(PRCM_BASE + 0x00A0) #endif #define PRM_RSTST (PRM_RSTCTRL + 8) diff --git a/arch/arm/include/asm/arch-am33xx/omap.h b/arch/arm/include/asm/arch-am33xx/omap.h index e7576c1..777a456 100644 --- a/arch/arm/include/asm/arch-am33xx/omap.h +++ b/arch/arm/include/asm/arch-am33xx/omap.h @@ -32,7 +32,7 @@ #define NON_SECURE_SRAM_START 0x402F0400 #define NON_SECURE_SRAM_END0x4031 #define SRAM_SCRATCH_SPACE_ADDR0x4030C000 -#elif defined(CONFIG_TI814X) +#elif defined(CONFIG_TI81XX) #define NON_SECURE_SRAM_START 0x4030 #define NON_SECURE_SRAM_END0x4032 #define SRAM_SCRATCH_SPACE_ADDR0x4031B800 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index d77c25f..d659eb0 100644 --- a/drivers/serial/ns16550.c +++ b/drivers/serial/ns16550.c @@ -57,7 +57,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(CONFIG_SYS_NS16550_IER, com_port-ier); #if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \ - defined(CONFIG_AM33XX) || defined(CONFIG_TI814X) + defined(CONFIG_AM33XX) || defined(CONFIG_TI81XX) serial_out(0x7, com_port-mdr1); /* mode select reset TL16C750*/ #endif serial_out(UART_LCR_BKSE | UART_LCRVAL, com_port-lcr); @@ -72,7 +72,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor) serial_out(UART_LCRVAL, com_port-lcr); #if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \ defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX) || \ - defined(CONFIG_TI814X) + defined(CONFIG_TI81XX) /* /16 is proper to hit 115200 with 48MHz */ serial_out(0, com_port-mdr1); diff --git a/spl/Makefile b/spl/Makefile index d8fe948..3ea8ce0 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -84,7 +84,7 @@ LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/phy/libphy.o LIBS-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += drivers/usb/musb-new/libusb_musb-new.o LIBS-$(CONFIG_SPL_USBETH_SUPPORT) += drivers/usb/gadget/libusb_gadget.o -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI81XX),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/3] Add TI816X EVM support
This serie introduce the support of the TI816X EVM board. The serie fits into the existing AM33XX SoC support and reuse some definitions from the TI814X. Based on the implementation in the TI-PSP-04.00.02.14 vendor tree: http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary It has been tested booting up a Linux kernel on TI8168 refs F and C cards, with an MMC. SPL is working fine too. Changes for v4: - add arch_cpu_init function - rework the ddr initialization and move it to clock_ti816x.c - move common definitions from clock_ti814x.c to clock_ti81xx.h Changes for v3: - fix a compile error when using DDR2 - rename misspelled CONFIG_EXTRA_ENV_SETTINGS in ti816x_evm.h (was CONFIG_EXTRA_EMV_SETTINGS) Changes for v2: - patches 2-7 squashed into a single patch Add TI816X support - removed all unused definitions - removed my definition of DMM_BASE and reworked the DMM initialization using the common config_dmm() from emif4.c - fixed coding style problems - now use the fallback CONFIG_SYS_BAUDRATE_TABLE - kept LONGHELP support - removed redefinition of the device type section in cpu_ti816x.h Antoine Tenart (3): Prepare for TI816X : reuse existing code from TI814X Add TI816X support Add TI816X evm board support MAINTAINERS|4 + Makefile |2 +- arch/arm/cpu/armv7/Makefile|2 +- arch/arm/cpu/armv7/am33xx/Makefile |1 + arch/arm/cpu/armv7/am33xx/clock_ti814x.c | 95 arch/arm/cpu/armv7/am33xx/clock_ti816x.c | 529 arch/arm/cpu/armv7/am33xx/emif4.c |2 + arch/arm/cpu/armv7/omap-common/Makefile|2 +- arch/arm/include/asm/arch-am33xx/clock.h |4 + arch/arm/include/asm/arch-am33xx/clock_ti81xx.h| 142 ++ arch/arm/include/asm/arch-am33xx/cpu.h |2 +- arch/arm/include/asm/arch-am33xx/ddr_defs.h| 35 +- arch/arm/include/asm/arch-am33xx/hardware.h|7 +- arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |5 + arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |5 + arch/arm/include/asm/arch-am33xx/hardware_ti816x.h | 57 +++ arch/arm/include/asm/arch-am33xx/mmc_host_def.h|3 + arch/arm/include/asm/arch-am33xx/mux.h |2 + arch/arm/include/asm/arch-am33xx/mux_ti816x.h | 363 ++ arch/arm/include/asm/arch-am33xx/omap.h|2 +- arch/arm/include/asm/arch-am33xx/spl.h | 11 +- board/ti/ti816x/Makefile | 47 ++ board/ti/ti816x/evm.c | 249 + boards.cfg |1 + drivers/serial/ns16550.c |4 +- include/configs/ti816x_evm.h | 188 +++ spl/Makefile |2 +- 27 files changed, 1644 insertions(+), 122 deletions(-) create mode 100644 arch/arm/cpu/armv7/am33xx/clock_ti816x.c create mode 100644 arch/arm/include/asm/arch-am33xx/clock_ti81xx.h create mode 100644 arch/arm/include/asm/arch-am33xx/hardware_ti816x.h create mode 100644 arch/arm/include/asm/arch-am33xx/mux_ti816x.h create mode 100644 board/ti/ti816x/Makefile create mode 100644 board/ti/ti816x/evm.c create mode 100644 include/configs/ti816x_evm.h -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] Add TI816X support
Signed-off-by: Antoine Tenart aten...@adeneo-embedded.com
---
arch/arm/cpu/armv7/am33xx/Makefile |1 +
arch/arm/cpu/armv7/am33xx/clock_ti814x.c | 95
arch/arm/cpu/armv7/am33xx/clock_ti816x.c | 529
arch/arm/cpu/armv7/am33xx/emif4.c |2 +
arch/arm/include/asm/arch-am33xx/clock.h |4 +
arch/arm/include/asm/arch-am33xx/clock_ti81xx.h| 142 ++
arch/arm/include/asm/arch-am33xx/ddr_defs.h| 35 +-
arch/arm/include/asm/arch-am33xx/hardware.h|7 +-
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |5 +
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |5 +
arch/arm/include/asm/arch-am33xx/hardware_ti816x.h | 57 +++
arch/arm/include/asm/arch-am33xx/mmc_host_def.h|3 +
arch/arm/include/asm/arch-am33xx/mux.h |2 +
arch/arm/include/asm/arch-am33xx/mux_ti816x.h | 363 ++
arch/arm/include/asm/arch-am33xx/spl.h | 11 +-
15 files changed, 1147 insertions(+), 114 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/clock_ti816x.c
create mode 100644 arch/arm/include/asm/arch-am33xx/clock_ti81xx.h
create mode 100644 arch/arm/include/asm/arch-am33xx/hardware_ti816x.h
create mode 100644 arch/arm/include/asm/arch-am33xx/mux_ti816x.h
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index c97e30d..703d7a2 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -18,6 +18,7 @@ LIB = $(obj)lib$(SOC).o
COBJS-$(CONFIG_AM33XX) += clock_am33xx.o
COBJS-$(CONFIG_TI814X) += clock_ti814x.o
+COBJS-$(CONFIG_TI816X) += clock_ti816x.o
COBJS += sys_info.o
COBJS += mem.o
COBJS += ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
index 8b2878d..f7181de 100644
--- a/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
+++ b/arch/arm/cpu/armv7/am33xx/clock_ti814x.c
@@ -108,103 +108,8 @@ struct ad_pll {
#define OSC_SRC_CTRL (PLL_SUBSYS_BASE + 0x2C0)
-/* PRCM */
#define ENET_CLKCTRL_CMPL 0x3
-#define CM_DEFAULT_BASE(PRCM_BASE + 0x0500)
-
-struct cm_def {
- unsigned int resv0[2];
- unsigned int l3fastclkstctrl;
- unsigned int resv1[1];
- unsigned int pciclkstctrl;
- unsigned int resv2[1];
- unsigned int ducaticlkstctrl;
- unsigned int resv3[1];
- unsigned int emif0clkctrl;
- unsigned int emif1clkctrl;
- unsigned int dmmclkctrl;
- unsigned int fwclkctrl;
- unsigned int resv4[10];
- unsigned int usbclkctrl;
- unsigned int resv5[1];
- unsigned int sataclkctrl;
- unsigned int resv6[4];
- unsigned int ducaticlkctrl;
- unsigned int pciclkctrl;
-};
-
-#define CM_ALWON_BASE (PRCM_BASE + 0x1400)
-
-struct cm_alwon {
- unsigned int l3slowclkstctrl;
- unsigned int ethclkstctrl;
- unsigned int l3medclkstctrl;
- unsigned int mmu_clkstctrl;
- unsigned int mmucfg_clkstctrl;
- unsigned int ocmc0clkstctrl;
- unsigned int vcpclkstctrl;
- unsigned int mpuclkstctrl;
- unsigned int sysclk4clkstctrl;
- unsigned int sysclk5clkstctrl;
- unsigned int sysclk6clkstctrl;
- unsigned int rtcclkstctrl;
- unsigned int l3fastclkstctrl;
- unsigned int resv0[67];
- unsigned int mcasp0clkctrl;
- unsigned int mcasp1clkctrl;
- unsigned int mcasp2clkctrl;
- unsigned int mcbspclkctrl;
- unsigned int uart0clkctrl;
- unsigned int uart1clkctrl;
- unsigned int uart2clkctrl;
- unsigned int gpio0clkctrl;
- unsigned int gpio1clkctrl;
- unsigned int i2c0clkctrl;
- unsigned int i2c1clkctrl;
- unsigned int mcasp345clkctrl;
- unsigned int atlclkctrl;
- unsigned int mlbclkctrl;
- unsigned int pataclkctrl;
- unsigned int resv1[1];
- unsigned int uart3clkctrl;
- unsigned int uart4clkctrl;
- unsigned int uart5clkctrl;
- unsigned int wdtimerclkctrl;
- unsigned int spiclkctrl;
- unsigned int mailboxclkctrl;
- unsigned int spinboxclkctrl;
- unsigned int mmudataclkctrl;
- unsigned int resv2[2];
- unsigned int mmucfgclkctrl;
- unsigned int resv3[2];
- unsigned int ocmc0clkctrl;
- unsigned int vcpclkctrl;
- unsigned int resv4[2];
- unsigned int controlclkctrl;
- unsigned int resv5[2];
- unsigned int gpmcclkctrl;
- unsigned int ethernet0clkctrl;
- unsigned int ethernet1clkctrl;
- unsigned int mpuclkctrl;
- unsigned int debugssclkctrl;
- unsigned int l3clkctrl;
- unsigned int l4hsclkctrl;
- unsigned int l4lsclkctrl;
- unsigned int rtcclkctrl;
- unsigned int tpccclkctrl;
- unsigned int tptc0clkctrl;
- unsigned int tptc1clkctrl;
- unsigned int
Re: [U-Boot] please pull u-boot-samsung master
Hi Minkyu, On Mon, 17 Jun 2013 11:10:58 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) I had three merge conflicts here, two solved automatically (files drivers/mmc/mmc.c and include/mmc.h) and one manually (spl/Makefile). I have pushed the resulting branch as mastercandidate. Please confirm that the resolutions are ok. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Wed, Jun 19, 2013 at 6:09 AM, Minkyu Kang mk7.k...@samsung.com wrote: On 18/06/13 23:57, Albert ARIBAUD wrote: Hi Minkyu, On Mon, 17 Jun 2013 13:16:20 +0530, Jagan Teki jagannadh.t...@gmail.com wrote: On Mon, Jun 17, 2013 at 7:40 AM, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) Akshay Saraswat (2): Exynos5: clock: Update the equation to calculate PLL output frequency Exynos: uart: s5p: enabling the uart tx/rx fifo Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition Arkadiusz Wlodarczyk (1): arm:trats: change auto-booting to boot kernel with separate device tree blob Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init Naveen Krishna Chatradhi (2): power: exynos-tmu: fix warnings and clean up code power: exynos-tmu: use the mux_addr bit fields in tmu_control register Rajeshwari Shinde (3): SF: Add driver for Gigabyte device GD25LQ and GD25Q64B SMDK5250: Enable SPI Gigabyte device. SPI gigabyte flash driver is not available in drivers/mtd/spi/ Am i missing anything here, please help. gigabyte flash driver is available in drivers/mtd/spi/ please refer below link. http://git.denx.de/?p=u-boot/u-boot-samsung.git;a=blob;f=drivers/mtd/spi/gigadevice.c; My question is the driver is not yet in main line, but patch SMDK5250: Enable SPI Gigabyte device. is enabling the driver CONFIG_* into smdk5250 configuration entries. Is this valid, please correct me if am wrong. -- Thanks, Jagan. So, Minkyu, should I pick this PR or wait for an update? Please pick this PR. Amicalement, Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Jagan, On Wed, 19 Jun 2013 17:19:36 +0530, Jagan Teki jagannadh.t...@gmail.com wrote: On Wed, Jun 19, 2013 at 6:09 AM, Minkyu Kang mk7.k...@samsung.com wrote: On 18/06/13 23:57, Albert ARIBAUD wrote: Hi Minkyu, On Mon, 17 Jun 2013 13:16:20 +0530, Jagan Teki jagannadh.t...@gmail.com wrote: On Mon, Jun 17, 2013 at 7:40 AM, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) Akshay Saraswat (2): Exynos5: clock: Update the equation to calculate PLL output frequency Exynos: uart: s5p: enabling the uart tx/rx fifo Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition Arkadiusz Wlodarczyk (1): arm:trats: change auto-booting to boot kernel with separate device tree blob Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init Naveen Krishna Chatradhi (2): power: exynos-tmu: fix warnings and clean up code power: exynos-tmu: use the mux_addr bit fields in tmu_control register Rajeshwari Shinde (3): SF: Add driver for Gigabyte device GD25LQ and GD25Q64B SMDK5250: Enable SPI Gigabyte device. SPI gigabyte flash driver is not available in drivers/mtd/spi/ Am i missing anything here, please help. gigabyte flash driver is available in drivers/mtd/spi/ please refer below link. http://git.denx.de/?p=u-boot/u-boot-samsung.git;a=blob;f=drivers/mtd/spi/gigadevice.c; My question is the driver is not yet in main line, but patch SMDK5250: Enable SPI Gigabyte device. is enabling the driver CONFIG_* into smdk5250 configuration entries. Is this valid, please correct me if am wrong. Doesn't patch SMDK5250: Enable SPI Gigabyte device immediately follow patch SF: Add driver for Gigabyte device GD25LQ and GD25Q64B which creates said device? -- Thanks, Jagan. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Wed, Jun 19, 2013 at 5:24 PM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Jagan, On Wed, 19 Jun 2013 17:19:36 +0530, Jagan Teki jagannadh.t...@gmail.com wrote: On Wed, Jun 19, 2013 at 6:09 AM, Minkyu Kang mk7.k...@samsung.com wrote: On 18/06/13 23:57, Albert ARIBAUD wrote: Hi Minkyu, On Mon, 17 Jun 2013 13:16:20 +0530, Jagan Teki jagannadh.t...@gmail.com wrote: On Mon, Jun 17, 2013 at 7:40 AM, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) Akshay Saraswat (2): Exynos5: clock: Update the equation to calculate PLL output frequency Exynos: uart: s5p: enabling the uart tx/rx fifo Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition Arkadiusz Wlodarczyk (1): arm:trats: change auto-booting to boot kernel with separate device tree blob Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init Naveen Krishna Chatradhi (2): power: exynos-tmu: fix warnings and clean up code power: exynos-tmu: use the mux_addr bit fields in tmu_control register Rajeshwari Shinde (3): SF: Add driver for Gigabyte device GD25LQ and GD25Q64B SMDK5250: Enable SPI Gigabyte device. SPI gigabyte flash driver is not available in drivers/mtd/spi/ Am i missing anything here, please help. gigabyte flash driver is available in drivers/mtd/spi/ please refer below link. http://git.denx.de/?p=u-boot/u-boot-samsung.git;a=blob;f=drivers/mtd/spi/gigadevice.c; My question is the driver is not yet in main line, but patch SMDK5250: Enable SPI Gigabyte device. is enabling the driver CONFIG_* into smdk5250 configuration entries. Is this valid, please correct me if am wrong. Doesn't patch SMDK5250: Enable SPI Gigabyte device immediately follow patch SF: Add driver for Gigabyte device GD25LQ and GD25Q64B which creates said device? OK I couldn't observer actual commit prefix for this gigabyte flash driver. May it could have sf: gigabyte: Any way please continue- -- Thanks, Jagan. -- Thanks, Jagan. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [uBoot] [PATCH v2] musb: Move linux and usb compat files to include/linux/usb
+ Marek
and a bump
On 06/13/2013 02:07 PM, Dan Murphy wrote:
Move the linux and usb compat files to the
include/linux/usb directory in order for the files to be
reused.
Added GPLv2 license to the linux and usb compat as well.
Signed-off-by: Dan Murphy dmur...@ti.com
---
v2 - Fix checkpatch issues only for newly introduced code -
http://patchwork.ozlabs.org/patch/251127/
drivers/usb/musb-new/linux-compat.h| 114 --
drivers/usb/musb-new/musb_core.c |4 +-
drivers/usb/musb-new/musb_dsps.c |2 +-
drivers/usb/musb-new/musb_gadget.c |2 +-
drivers/usb/musb-new/musb_gadget_ep0.c |2 +-
drivers/usb/musb-new/musb_host.c |4 +-
drivers/usb/musb-new/musb_host.h |2 +-
drivers/usb/musb-new/musb_uboot.c |4 +-
drivers/usb/musb-new/usb-compat.h | 88
include/linux/usb/linux-compat.h | 136
include/linux/usb/usb-compat.h | 110 ++
11 files changed, 256 insertions(+), 212 deletions(-)
delete mode 100644 drivers/usb/musb-new/linux-compat.h
delete mode 100644 drivers/usb/musb-new/usb-compat.h
create mode 100644 include/linux/usb/linux-compat.h
create mode 100644 include/linux/usb/usb-compat.h
diff --git a/drivers/usb/musb-new/linux-compat.h
b/drivers/usb/musb-new/linux-compat.h
deleted file mode 100644
index 72c8c2b..000
--- a/drivers/usb/musb-new/linux-compat.h
+++ /dev/null
@@ -1,114 +0,0 @@
-#ifndef __LINUX_COMPAT_H__
-#define __LINUX_COMPAT_H__
-
-#include malloc.h
-#include linux/list.h
-#include linux/compat.h
-
-#define __init
-#define __devinit
-#define __devinitdata
-#define __devinitconst
-#define __iomem
-#define __deprecated
-
-struct unused {};
-typedef struct unused unused_t;
-
-typedef int irqreturn_t;
-typedef unused_t spinlock_t;
-
-struct work_struct {};
-
-struct timer_list {};
-struct notifier_block {};
-
-typedef unsigned long dmaaddr_t;
-
-#define spin_lock_init(lock) do {} while (0)
-#define spin_lock(lock) do {} while (0)
-#define spin_unlock(lock) do {} while (0)
-#define spin_lock_irqsave(lock, flags) do {} while (0)
-#define spin_unlock_irqrestore(lock, flags) do {} while (0)
-
-#define setup_timer(timer, func, data) do {} while (0)
-#define del_timer_sync(timer) do {} while (0)
-#define schedule_work(work) do {} while (0)
-#define INIT_WORK(work, fun) do {} while (0)
-
-#define cpu_relax() do {} while (0)
-
-#define pr_debug(fmt, args...) debug(fmt, ##args)
-#define dev_dbg(dev, fmt, args...) \
- debug(fmt, ##args)
-#define dev_vdbg(dev, fmt, args...) \
- debug(fmt, ##args)
-#define dev_info(dev, fmt, args...) \
- printf(fmt, ##args)
-#define dev_err(dev, fmt, args...) \
- printf(fmt, ##args)
-#define printk printf
-
-#define WARN(condition, fmt, args...) ({ \
- int ret_warn = !!condition; \
- if (ret_warn) \
- printf(fmt, ##args);\
- ret_warn; })
-
-#define KERN_DEBUG
-#define KERN_NOTICE
-#define KERN_WARNING
-#define KERN_ERR
-
-#define kfree(ptr) free(ptr)
-
-#define pm_runtime_get_sync(dev) do {} while (0)
-#define pm_runtime_put(dev) do {} while (0)
-#define pm_runtime_put_sync(dev) do {} while (0)
-#define pm_runtime_use_autosuspend(dev) do {} while (0)
-#define pm_runtime_set_autosuspend_delay(dev, delay) do {} while (0)
-#define pm_runtime_enable(dev) do {} while (0)
-
-#define MODULE_DESCRIPTION(desc)
-#define MODULE_AUTHOR(author)
-#define MODULE_LICENSE(license)
-#define MODULE_ALIAS(alias)
-#define module_param(name, type, perm)
-#define MODULE_PARM_DESC(name, desc)
-#define EXPORT_SYMBOL_GPL(name)
-
-#define writesl(a, d, s) __raw_writesl((unsigned long)a, d, s)
-#define readsl(a, d, s) __raw_readsl((unsigned long)a, d, s)
-#define writesw(a, d, s) __raw_writesw((unsigned long)a, d, s)
-#define readsw(a, d, s) __raw_readsw((unsigned long)a, d, s)
-#define writesb(a, d, s) __raw_writesb((unsigned long)a, d, s)
-#define readsb(a, d, s) __raw_readsb((unsigned long)a, d, s)
-
-#define IRQ_NONE 0
-#define IRQ_HANDLED 0
-
-#define dev_set_drvdata(dev, data) do {} while (0)
-
-#define disable_irq_wake(irq) do {} while (0)
-#define enable_irq_wake(irq) -EINVAL
-#define free_irq(irq, data) do {} while (0)
-#define request_irq(nr, f, flags, nm, data) 0
-
-#define device_init_wakeup(dev, a) do {} while (0)
-
-#define platform_data device_data
-
-#ifndef wmb
-#define wmb()asm volatile ( : : : memory)
-#endif
-
-#define msleep(a)udelay(a * 1000)
-
-/*
- * Map U-Boot config options to Linux ones
- */
-#ifdef CONFIG_OMAP34XX
-#define CONFIG_SOC_OMAP3430
-#endif
-
-#endif /* __LINUX_COMPAT_H__ */
diff --git a/drivers/usb/musb-new/musb_core.c
b/drivers/usb/musb-new/musb_core.c
index
Re: [U-Boot] please pull u-boot-samsung master
On 19/06/13 20:30, Albert ARIBAUD wrote: Hi Minkyu, On Mon, 17 Jun 2013 11:10:58 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) I had three merge conflicts here, two solved automatically (files drivers/mmc/mmc.c and include/mmc.h) and one manually (spl/Makefile). I have pushed the resulting branch as mastercandidate. Please confirm that the resolutions are ok. It's good. confirmed. Amicalement, Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu: make data buffer size configurable
Dear Heiko Schocher, Dfu transfer uses a buffer before writing data to the raw storage device. Make the size (in bytes) of this buffer configurable through environment variable dfu_bufsiz. Defaut value is configurable through CONFIG_SYS_DFU_DATA_BUF_SIZE Signed-off-by: Heiko Schocher h...@denx.de Cc: Pantelis Antoniou pa...@antoniou-consulting.com Cc: Tom Rini tr...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Marek Vasut ma...@denx.de Cc: Wolfgang Denk w...@denx.de Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/1] NET: Fix system hanging if NET device is not installed
On Fri, May 17, 2013 at 05:41:03PM +0800, Jim Lin wrote: If we try to boot from NET device, NetInitLoop in net.c will be invoked. If NET device is not installed, eth_get_dev() function will return eth_current value, which is NULL. When NetInitLoop is called, eth_get_dev-enetaddr will access restricted memory area and therefore cause hanging. This issue is found on Tegra30 Cardhu platform after adding CONFIG_CMD_NET and CONFIG_CMD_DHCP in config header file. Signed-off-by: Jim Lin ji...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com 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 0/8] rely on latest dtc, simplify
On Tue, Jun 11, 2013 at 12:19:52PM -0400, Tom Rini wrote: On Mon, Jun 10, 2013 at 05:16:56PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This is a series of patches which simplifies the rules to build *.dts in U-Boot by relying on features in the latest dtc. The include rules are made more consistent between cpp (when processing *.dts) and dtc. The cpp flags are made more consistent with the way the kernel processes *.dts to allow better portability of *.dts between the two. Please add a dtc-version Makefile variable and corresponding tools/dtc-version.sh script, ala gcc/binutils so that we can error out gracefully if dtc isn't supporting the options we need. For clarity, we need some sort of graceful error-out, be it version check or flag-is-supported check. I fear this is going to lead to a lot of people not being able to compile and I'd like to be able to give a clear error message. -- 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] nand onfi 8bit/16bit bus support
Hi Scott, On 05/09/2013 11:37 PM, Scott Wood wrote: On 05/06/2013 11:53:52 AM, Michal Simek wrote: Hi guys, Zynq supports 8 and 16bit ONFI nand flashes. We can count number of connected pins and from that we know if 8bit or 16bit nand flash is used. I have looked at the code and contains ONFI detection with correct detection of bus width + checking later. Why also not setup proper chip-options for NAND_BUSWIDTH_16? Not sure how others but if driver expect just ONFI devices and support 8 and 16bit options why not just to setup chip options based on information from ONFI or not check that (busw != (chip-options NAND_BUSWIDTH_16)) for onfi case. This is fixed in current Linux, with NAND_BUSWIDTH_AUTO. There was a patchset to merge in recent Linux MTD code a while back, but an expected respin didn't come. I'll try to fix it up when I process this merge window's patches. Have you done this change? I have grepped the latest version and I can't see it there. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
On Wed, Jun 19, 2013 at 10:44 AM, Axel Lin axel@ingics.com wrote:
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
writel(value gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
Should do no? This would avoid the if block.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
Dear Axel Lin,
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
You might want to use clrbits_le32() and setbits_le32() here, no?
return 0;
}
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
2013/6/19 Marek Vasut ma...@denx.de:
Dear Axel Lin,
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
You might want to use clrbits_le32() and setbits_le32() here, no?
Honestly, I ask this because I cannot find the detail datasheet for the gpio
control of this device. ( Just found the code looks strange).
Usually we can use clrbits_le32() and setbits_le32() helpers to set/clear
register bits. But if the only meaningful bit is 1 gpio, simply use
write 1 gpio and write 0 saves a register read operation.
So maybe Stefan or someone from ST can provide the information about gpio
control on this hardware.
Regards,
Axel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
On 19.06.2013 16:01, Axel Lin wrote: - writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]); + if (value) + writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]); + else + writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]); You might want to use clrbits_le32() and setbits_le32() here, no? Honestly, I ask this because I cannot find the detail datasheet for the gpio control of this device. ( Just found the code looks strange). Usually we can use clrbits_le32() and setbits_le32() helpers to set/clear register bits. But if the only meaningful bit is 1 gpio, simply use write 1 gpio and write 0 saves a register read operation. So maybe Stefan or someone from ST can provide the information about gpio control on this hardware. I honestly have no idea how I tested this GPIO driver. That was too long ago. And I don't have the time to dig out the hardware to do some re-testing. But the code definitely looks wrong, so thanks for catching this. Let's wait what the ST engineers have to comment here. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] rely on latest dtc, simplify
On 06/19/2013 06:46 AM, Tom Rini wrote: On Tue, Jun 11, 2013 at 12:19:52PM -0400, Tom Rini wrote: On Mon, Jun 10, 2013 at 05:16:56PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This is a series of patches which simplifies the rules to build *.dts in U-Boot by relying on features in the latest dtc. The include rules are made more consistent between cpp (when processing *.dts) and dtc. The cpp flags are made more consistent with the way the kernel processes *.dts to allow better portability of *.dts between the two. Please add a dtc-version Makefile variable and corresponding tools/dtc-version.sh script, ala gcc/binutils so that we can error out gracefully if dtc isn't supporting the options we need. For clarity, we need some sort of graceful error-out, be it version check or flag-is-supported check. I fear this is going to lead to a lot of people not being able to compile and I'd like to be able to give a clear error message. I've implemented this check and have the patches ready. I'm just waiting for a dtc release that has all the required features, so that there actually is a version number the code can check for. It sounds like there's agreement to make the dtc release by the end of this week, unless anyone comes forward and objects, and they haven't yet:-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] rely on latest dtc, simplify
On Wed, Jun 19, 2013 at 09:38:17AM -0600, Stephen Warren wrote: On 06/19/2013 06:46 AM, Tom Rini wrote: On Tue, Jun 11, 2013 at 12:19:52PM -0400, Tom Rini wrote: On Mon, Jun 10, 2013 at 05:16:56PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com This is a series of patches which simplifies the rules to build *.dts in U-Boot by relying on features in the latest dtc. The include rules are made more consistent between cpp (when processing *.dts) and dtc. The cpp flags are made more consistent with the way the kernel processes *.dts to allow better portability of *.dts between the two. Please add a dtc-version Makefile variable and corresponding tools/dtc-version.sh script, ala gcc/binutils so that we can error out gracefully if dtc isn't supporting the options we need. For clarity, we need some sort of graceful error-out, be it version check or flag-is-supported check. I fear this is going to lead to a lot of people not being able to compile and I'd like to be able to give a clear error message. I've implemented this check and have the patches ready. I'm just waiting for a dtc release that has all the required features, so that there actually is a version number the code can check for. It sounds like there's agreement to make the dtc release by the end of this week, unless anyone comes forward and objects, and they haven't yet:-) Sounds good to me, 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-samsung master
Hi Minkyu, On Mon, 17 Jun 2013 11:10:58 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit d0a51373131c4ba565a2391d5ed78b87c406ce98: at91sam9260ek: move board id setup to config header (2013-05-12 16:49:14 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to ed7bdc03eb516fb698ccc12ec5b4b9f132d05c5f: MMC: DWMMC: Fix FIFO_DEPTH calculation (2013-06-17 11:03:42 +0900) Akshay Saraswat (2): Exynos5: clock: Update the equation to calculate PLL output frequency Exynos: uart: s5p: enabling the uart tx/rx fifo Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5: DWMMC: Initialise the local variable to avoid unwanted results. SMDK5250: Initialise and Enable DWMMC, support FDT and non-FDT MMC: APIs to support resize of EMMC boot partition SMDK5250: Enable EMMC booting COMMON: MMC: Command to support EMMC booting and to resize EMMC boot partition Arkadiusz Wlodarczyk (1): arm:trats: change auto-booting to boot kernel with separate device tree blob Inderpal Singh (3): exynos: move tzpc_init to armv7/exynos exynos: update tzpc to make it common for exynos4 and exynos5 exynos: Update origen and smdkv310 to use common tzpc_init Naveen Krishna Chatradhi (2): power: exynos-tmu: fix warnings and clean up code power: exynos-tmu: use the mux_addr bit fields in tmu_control register Rajeshwari Shinde (3): SF: Add driver for Gigabyte device GD25LQ and GD25Q64B SMDK5250: Enable SPI Gigabyte device. MMC: DWMMC: Fix FIFO_DEPTH calculation arch/arm/cpu/armv7/exynos/Makefile |2 +- arch/arm/cpu/armv7/exynos/clock.c | 10 +- .../arm/cpu/armv7/exynos/tzpc.c| 25 +- arch/arm/cpu/armv7/s5p-common/Makefile |2 + arch/arm/dts/exynos5250.dtsi | 33 ++ arch/arm/include/asm/arch-exynos/cpu.h |4 + arch/arm/include/asm/arch-exynos/dwmmc.h | 11 +- arch/arm/include/asm/arch-exynos/tmu.h | 58 ++- arch/arm/include/asm/arch-exynos/tzpc.h| 20 + board/samsung/dts/exynos5250-smdk5250.dts | 24 ++ board/samsung/origen/lowlevel_init.S | 44 +- board/samsung/origen/origen_setup.h| 25 -- board/samsung/smdk5250/Makefile|5 +- board/samsung/smdk5250/clock_init.c| 18 + board/samsung/smdk5250/clock_init.h|5 + board/samsung/smdk5250/exynos5-dt.c| 423 board/samsung/smdk5250/lowlevel_init.S |2 + board/samsung/smdk5250/setup.h | 25 -- board/samsung/smdk5250/smdk5250.c | 223 +++ board/samsung/smdk5250/spl_boot.c | 64 ++- board/samsung/smdkv310/lowlevel_init.S | 60 +-- common/cmd_mmc.c | 109 - doc/device-tree-bindings/exynos/dwmmc.txt | 54 +++ drivers/mmc/dw_mmc.c | 27 +- drivers/mmc/exynos_dw_mmc.c| 127 +- drivers/mmc/mmc.c | 134 +++ drivers/mtd/spi/Makefile |1 + drivers/mtd/spi/gigadevice.c | 81 drivers/mtd/spi/spi_flash.c|3 + drivers/mtd/spi/spi_flash_internal.h |1 + drivers/power/exynos-tmu.c | 123 +++--- drivers/serial/serial_s5p.c| 13 +- drivers/video/exynos_fb.c |4 +- include/configs/exynos5250-dt.h| 11 +- include/configs/origen.h |2 + include/configs/smdkv310.h |2 + include/configs/trats.h| 17 +- include/dwmmc.h|3 + include/fdtdec.h |1 + include/mmc.h | 26 ++ lib/fdtdec.c |1 + spl/Makefile |4 + 42 files changed, 1356 insertions(+), 471 deletions(-) rename board/samsung/smdk5250/tzpc_init.c = arch/arm/cpu/armv7/exynos/tzpc.c (69%) create mode 100644 board/samsung/smdk5250/exynos5-dt.c create mode 100644 doc/device-tree-bindings/exynos/dwmmc.txt create mode 100644 drivers/mtd/spi/gigadevice.c Applied to u-boot-arm/master, thanks!
Re: [U-Boot] [PATCH 10/10] powerpc: p1022ds: support TPL on the P1022DS
On Tue, Jun 18, 2013 at 12:54 PM, Scott Wood scottw...@freescale.comwrote: On 06/18/2013 10:37:02 AM, Timur Tabi wrote: On Tue, Jun 18, 2013 at 5:39 AM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com Support TPL on the P1022DS. Please define TPL. I have no idea what it is. Third Program Loader. An additional stage that comes after SPL, before the main image. But yes, the commit message and README should explain this. I'm having a great deal of difficulty understanding your patch numbering system. This patch is 10/10, and I see 5/10 and 9/10. Where are 1-4 and 7-8? I also see some unnumbered, unversioned patches (despite the fact that they are clearly part of a series, and not the first versions of the patch submitted). I also see a series of 4 patches, which are marked as being a series of 8 patches, and we only see 2, 5, 6, and 8. Please: 1) Put version numbers on your patches. The version should increment each time you send the patch out (even if it hasn't changed. It helps keep the patch series coherent). You don't need a version number on the first instance of the patch 2) Put a changelog for your patch below the ---, which describes the change history of that patch. If you are on v5, there should be 4 changelogs, so we see how the patch has changed over time. If it doesn't change, just put no change 3) If a set of patches are related to each other, then put them in a series, and number them x/n, where x is 1-n. I suspect that this particular numbering oddness is caused by generating 10 patches, and then only submitting 3 of them (perhaps because the others are already up-to-date). Please default to re-sending all patches in a series. It is fairly trivial to notice in patchworks, and much easier to ensure that I've actually seen all the relevant patches. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/p1022ds: boot from spi flash with SPL
On Fri, Jun 7, 2013 at 4:25 AM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com Support to boot from spi flash. This patch is on top of the patch: powerpc/p1022ds: boot from SD Card with SPL Signed-off-by: Ying Zhang b40...@freescale.com --- board/freescale/p1022ds/spl.c | 12 +- drivers/mtd/spi/Makefile |1 + drivers/mtd/spi/fsl_espi_spl.c | 79 drivers/mtd/spi/spi_flash.c|2 + include/configs/P1022DS.h | 36 +++ These should probably be divided into two patches. One to add the capability (in drivers/mtd), and one to enable the capability (in the p1022-specific files). I'd like jagan's ack before applying this, but if you split this patch, and he agrees, I'd be happy to take this in through my tree. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand onfi 8bit/16bit bus support
On 06/19/2013 08:40:19 AM, Michal Simek wrote: Hi Scott, On 05/09/2013 11:37 PM, Scott Wood wrote: On 05/06/2013 11:53:52 AM, Michal Simek wrote: Hi guys, Zynq supports 8 and 16bit ONFI nand flashes. We can count number of connected pins and from that we know if 8bit or 16bit nand flash is used. I have looked at the code and contains ONFI detection with correct detection of bus width + checking later. Why also not setup proper chip-options for NAND_BUSWIDTH_16? Not sure how others but if driver expect just ONFI devices and support 8 and 16bit options why not just to setup chip options based on information from ONFI or not check that (busw != (chip-options NAND_BUSWIDTH_16)) for onfi case. This is fixed in current Linux, with NAND_BUSWIDTH_AUTO. There was a patchset to merge in recent Linux MTD code a while back, but an expected respin didn't come. I'll try to fix it up when I process this merge window's patches. Have you done this change? I have grepped the latest version and I can't see it there. MTD from 3.7.1 (which was what was current when the patch was posted months ago) was merged in. It looks like NAND_BUSWIDTH_AUTO was added in 3.8. We can do another MTD update in the next merge window, which would pick this up. Or if you'd like to submit a patch that just fixes this problem (in the same way as in Linux, so it doesn't conflict too badly when we do the merge), it could be applied now as a bugfix. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] xilinx: move microblaze-generic .dts to standard location
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com Aside from microblaze, all other SoCs/boards/vendors store their DT files in board/$vendor/dts/$soc-$board.dts. Move microblaze-generic.dts to this location for consistency. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] dts/Makefile: simplify dtc invocation
Hi Stephen,
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.orgwrote:
From: Stephen Warren swar...@nvidia.com
The invocation of dtc is significantly more complex that it could be,
in order to work around an issue on old versions of dtc, which print
a message to stdout every time they run.
Remove this workaround, on the assumption that people have or will
upgrade to a newer version of dtc. This simplifies the build rule
significantly.
Related, split the invocation of cpp and dtc into separate commands
rather than a pipeline, so that if either fail, it is detected. This has
the nice benefit of saving off the result of the pre-processing step,
allowing it to be easily inspected.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
.gitignore | 1 +
dts/Makefile | 9 ++---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/.gitignore b/.gitignore
index 4116448..be9abd6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -16,6 +16,7 @@
*.patch
*.bin
*.cfgtmp
+*.dtstmp
# Build tree
/build-*
diff --git a/dts/Makefile b/dts/Makefile
index 03e163e..4d81d79 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -51,13 +51,8 @@ all: $(obj).depend $(LIB)
DT_BIN := $(obj)dt.dtb
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
- rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
- echo $$? 3 ; } | \
- grep -v '^DTC: dts-dtb on file' ; \
- } 31 12 ) ; \
- exit $$rc
+ $(CPP) -P $(DTS_CPPFLAGS) $ -o $(DT_BIN).dtstmp
+ $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
When you get an error here, will dtc report a bogus filename? Or will the
CPP line information deal with that - iwc please add a comment to the
commit message.
process_lds = \
$(1) | sed -r -n 's/^OUTPUT_$(2)[ (]*([^)]*).*/\1/p'
--
1.8.1.5
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] dts/Makefile: simplify dtc invocation
On 06/19/2013 02:37 PM, Simon Glass wrote:
Hi Stephen,
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.org
mailto:swar...@wwwdotorg.org wrote:
...
Related, split the invocation of cpp and dtc into separate commands
rather than a pipeline, so that if either fail, it is detected. This has
the nice benefit of saving off the result of the pre-processing step,
allowing it to be easily inspected.
...
diff --git a/.gitignore b/.gitignore
...
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
...
+ $(CPP) -P $(DTS_CPPFLAGS) $ -o $(DT_BIN).dtstmp
+ $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
When you get an error here, will dtc report a bogus filename? Or will
the CPP line information deal with that - iwc please add a comment to
the commit message.
Added this to commit description:
Assuming a new enough dtc (which an earlier patch enforces), dtc will
parse #line directives in its input file, and generate correct file and
line numbers in error messages, even though cpp is unconditionally
applied to its input file.
(note the patch that refers to will be new in v2 of the series).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] dts/Makefile: unify cpp/dtc include paths
Hi Stephen,
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.orgwrote:
From: Stephen Warren swar...@nvidia.com
*.dts may use #include (via cpp) or /include/ (via dtc; assuming a newer
dtc). The choice is up to the creator of the DT. Create a common variable
DTC_INCDIRS that lists the paths searched by include statements, and
update cpp and dtc invocation to use them.
For cpp, also specify -nostdinc to ensure the same set of paths is
available to both type of include statement.
For dtc, create a new DTC_FLAGS variable to hold all the flags passed to
dtc.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
---
dts/Makefile | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/dts/Makefile b/dts/Makefile
index 4d81d79..ec89f8b 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -52,7 +59,7 @@ DT_BIN:= $(obj)dt.dtb
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
$(CPP) -P $(DTS_CPPFLAGS) $ -o $(DT_BIN).dtstmp
- $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
+ $(DTC) $(DTC_FLAGS) -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
.dts.tmp perhaps?
process_lds = \
$(1) | sed -r -n 's/^OUTPUT_$(2)[ (]*([^)]*).*/\1/p'
--
1.8.1.5
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] dt: don't use ARCH_CPU_DTS
On Mon, Jun 10, 2013 at 4:17 PM, Stephen Warren swar...@wwwdotorg.orgwrote:
From: Stephen Warren swar...@nvidia.com
Now that we assume dtc supports the -i option, we don't need to use
ARCH_CPU_DTS in *.dts{,i}; we simply specify the include filename
directly, and dtc will find it.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] dts/Makefile: don't define ARCH_CPU_DTS, BOARD_DTS
On Mon, Jun 10, 2013 at 4:17 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com Now that nothing uses the defines ARCH_CPU_DTS, BOARD_DTS, stop defining them. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] config: don't define CONFIG_ARCH_DEVICE_TREE
On Mon, Jun 10, 2013 at 4:17 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com Now that nothing uses CONFIG_ARCH_DEVICE_TREE, stop defining it. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org --- arch/arm/cpu/armv7/tegra114/config.mk | 19 --- arch/arm/cpu/armv7/tegra20/config.mk | 26 -- arch/arm/cpu/armv7/tegra30/config.mk | 19 --- arch/microblaze/config.mk | 2 -- arch/x86/cpu/coreboot/config.mk | 23 --- doc/README.fdt-control| 3 +-- include/configs/exynos5250-dt.h | 1 - 7 files changed, 1 insertion(+), 92 deletions(-) delete mode 100644 arch/arm/cpu/armv7/tegra114/config.mk delete mode 100644 arch/arm/cpu/armv7/tegra20/config.mk delete mode 100644 arch/arm/cpu/armv7/tegra30/config.mk delete mode 100644 arch/x86/cpu/coreboot/config.mk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] dts/Makefile: unify cpp/dtc include paths
On 06/19/2013 02:51 PM, Simon Glass wrote:
Hi Stephen,
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.org
mailto:swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com mailto:swar...@nvidia.com
*.dts may use #include (via cpp) or /include/ (via dtc; assuming a newer
dtc). The choice is up to the creator of the DT. Create a common
variable
DTC_INCDIRS that lists the paths searched by include statements, and
update cpp and dtc invocation to use them.
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
$(CPP) -P $(DTS_CPPFLAGS) $ -o $(DT_BIN).dtstmp
- $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
+ $(DTC) $(DTC_FLAGS) -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
.dts.tmp perhaps?
I chose dtstmp to match *.cfgtmp which I found in .gitignore. Still, I
have no idea what those files are, so there's probably no reason to be
consistent with them. I can change this if you want (in patch 2/8).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] dts/Makefile: don't use cpp -P
On Mon, Jun 10, 2013 at 4:17 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com Recent dtc supports #line directives in the input source code, and even uses them to generate useful line numbers in any messages it emits. Stop passing -P to cpp, since there's no need any more. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dts/Makefile: pass -undef -D__DTS__ to cpp
On Mon, Jun 10, 2013 at 4:17 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com This brings U-Boot's cpp invocation into line with the way the Linux kernel invokes cpp on device trees. Consistency will be useful to ensure *.dts is portable between the two. -undef also has the added advantage of not defining linux, so DT property names such as linux,keymap don't get mangled. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org This series looks good and I'm pleased that it seems we are now able to drop support for the older dtc. It is slightly concerning that there has been no new dtc release for so long, but we should try to minimise the pain caused to U-Boot. We have local patches which enable building multiple .dts files as the kernel does. Once this lands we can perhaps send out a patch or two for that. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sf: Unify spi_flash write code
Hi Jagan, On Wed, Jun 19, 2013 at 2:56 AM, Jagan Teki jagannadh.t...@gmail.comwrote: On Wed, Jun 19, 2013 at 10:01 AM, Simon Glass s...@chromium.org wrote: Hi Jagan, On Fri, Jun 14, 2013 at 1:18 PM, Jagannadha Sutradharudu Teki jagannadha.sutradharudu-t...@xilinx.com wrote: Move common flash write code into spi_flash_write_common(). Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com --- drivers/mtd/spi/spi_flash.c | 122 --- drivers/mtd/spi/spi_flash_internal.h | 6 ++ 2 files changed, 60 insertions(+), 68 deletions(-) This looks good except that spi_flash_write_common() is not a great name - only one of the operations is a 'write'. Perhaps spi_flash_oper_common() or similar? I think it's ok to use spi_flash_write_common(). because, I put this name as the write sequence has all theseopers write_enable, write and wait_ready, not by taking only write operation. OK well let's not worry about it too much. Acked-by: Simon Glass s...@chromium.org May be I will try to put spi_flash_write_oper_common() Any comments.?? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] dts/Makefile: unify cpp/dtc include paths
On Wed, Jun 19, 2013 at 1:56 PM, Stephen Warren swar...@wwwdotorg.orgwrote:
On 06/19/2013 02:51 PM, Simon Glass wrote:
Hi Stephen,
On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.org
mailto:swar...@wwwdotorg.org wrote:
From: Stephen Warren swar...@nvidia.com mailto:swar...@nvidia.com
*.dts may use #include (via cpp) or /include/ (via dtc; assuming a
newer
dtc). The choice is up to the creator of the DT. Create a common
variable
DTC_INCDIRS that lists the paths searched by include statements, and
update cpp and dtc invocation to use them.
$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
$(CPP) -P $(DTS_CPPFLAGS) $ -o $(DT_BIN).dtstmp
- $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
+ $(DTC) $(DTC_FLAGS) -O dtb -o ${DT_BIN} $(DT_BIN).dtstmp
.dts.tmp perhaps?
I chose dtstmp to match *.cfgtmp which I found in .gitignore. Still, I
have no idea what those files are, so there's probably no reason to be
consistent with them. I can change this if you want (in patch 2/8).
OK thanks.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/5] Build arch/$ARCH/lib/bootm.o depending on CONFIG_CMD_BOOTM
On Wed, Jun 12, 2013 at 3:08 AM, dirk.eib...@gdsys.cc wrote: From: Dirk Eibach eib...@gdsys.de MAKEALL is fine for ppc4xx and mpc85xx. Run checks were done on our controlcenterd hardware. Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc Signed-off-by: Dirk Eibach dirk.eib...@gdsys.cc You don't need two sign-offs. Does anyone have comments on these patches? This one seems reasonable to me, if a bit scary. Can others test this? Dirk has already tested this on my systems. I'm not really sure these patches belong in my queue, but I can apply them if other custodians give their sign-off. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Bring in new I2C framework
Hi Heiko, On Sun, May 19, 2013 at 11:13 PM, Piotr Wilczek p.wilc...@samsung.comwrote: Hi Simon, -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Saturday, May 18, 2013 7:41 PM To: Piotr Wilczek Cc: Heiko Schocher; U-Boot Mailing List; Dirk Eibach; Stefan Roese; Holger Brunck; Mike Frysinger; Stephen Warren; Minkyu Kang Subject: Re: [PATCH v3 0/9] Bring in new I2C framework Hi Piotr, On Fri, May 17, 2013 at 6:17 AM, Piotr Wilczek p.wilc...@samsung.com wrote: Dear Heiko, -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Saturday, May 04, 2013 2:02 PM To: u-boot@lists.denx.de Cc: Heiko Schocher; Dirk Eibach; Stefan Roese; Simon Glass; Piotr Wilczek; Holger Brunck; Mike Frysinger; Stephen Warren Subject: [PATCH v3 0/9] Bring in new I2C framework It seems the timing is coming, to bring this finally in mainline and move boards over to the new i2c framework. Changes for v3 series: - Compiler collects the used i2c adapters in _u_boot_list_i2c, so no need for defining the used i2c adpaters in the board config file. - drop CONFIG_SYS_NUM_I2C_ADAPTERS and CONFIG_SYS_I2C_ADAPTERS - Some adaptions for the keymile boards, so we can drop CONFIG_I2C_MUX completely - add ppc4xx_i2c driver, ported from Dirk Eibach Serie compiles clean on arm and powerpc Ported i2c drivers: soft_i2c : from me, tested on some arm and powerpc boards fsl_i2c : from me, only compile tested tegra_i2c : ported from Simon Glass ppc4xx_i2c: adapted from Dirk Eibach dirk.eib...@gdsys.cc tested on (which board?) with 4 soft_i2c drivers and one ppc4x_i2c driver. Cc: Dirk Eibach dirk.eib...@gdsys.cc Cc: Stefan Roese s...@denx.de Cc: Simon Glass s...@chromium.org Cc: Piotr Wilczek p.wilc...@samsung.com Cc: Holger Brunck holger.bru...@keymile.com Cc: Mike Frysinger vap...@gentoo.org Cc: Stephen Warren swar...@wwwdotorg.org I ported s3c24x0_i2c driver and tested this framework on Samsung tree on Trats2 board. Please can you send a patch for this port? I posted that patch and some others with series introducing Trsts2, where I want to use this framework. I'm sorry I didn't mention it in my first mail. http://patchwork.ozlabs.org/patch/244645/ http://patchwork.ozlabs.org/patch/244644/ . http://patchwork.ozlabs.org/patch/244638/ http://patchwork.ozlabs.org/patch/244637/ http://patchwork.ozlabs.org/patch/244640/ http://patchwork.ozlabs.org/patch/244636/ What is the status of this series now please? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix for incorrect conversion hex string to number (FMAN firmware address).
--- arch/powerpc/cpu/mpc85xx/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c index 24eb978..ece1336 100644 --- a/arch/powerpc/cpu/mpc85xx/fdt.c +++ b/arch/powerpc/cpu/mpc85xx/fdt.c @@ -492,7 +492,7 @@ void fdt_fixup_fman_firmware(void *blob) if (!p) return; - fmanfw = (struct qe_firmware *) simple_strtoul(p, NULL, 0); + fmanfw = (struct qe_firmware *) simple_strtoul(p, NULL, 16); if (!fmanfw) return; -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] ARM: switch to non-secure state during bootm execution
On Thu, Jun 13, 2013 at 01:01:10PM +0200, Andre Przywara wrote:
To actually trigger the non-secure switch we just implemented, call
the switching routine from within the bootm command implementation.
This way we automatically enable this feature without further user
intervention.
The core specific part of the work is done in the assembly routine
in nonsec_virt.S, introduced with the previous patch, but for the full
glory we need to setup the GIC distributor interface once for the
whole system, which is done in C here.
The routine is placed in arch/arm/lib to allow easy access from
different boards or CPUs.
We check the availability of the security extensions first.
The generic timer base frequency register is only accessible from
secure state, so we have to program it now. Actually this should be
done from primary firmware before, but some boards seems to omit
this, so if needed we do this here with a board specific value.
The Versatile Express board does not need this, so we remove the
frequency from the configuration file here.
Since we need a safe way to access the GIC, we use the PERIPHBASE
registers on Cortex-A15 and A7 CPUs and do some sanity checks.
Board not implementing the CBAR can override this value via a
configuration file variable.
Then we actually do the GIC enablement:
a) enable the GIC distributor, both for non-secure and secure state
(GICD_CTLR[1:0] = 11b)
b) allow all interrupts to be handled from non-secure state
(GICD_IGROUPRn = 0x)
The core specific GIC setup is then done in the assembly routine.
The actual bootm trigger is pretty small: calling the routine and
doing some error reporting.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/include/asm/armv7.h| 7 ++
arch/arm/lib/Makefile | 2 +
arch/arm/lib/bootm.c| 20 ++
arch/arm/lib/virt-v7.c | 137
include/configs/vexpress_ca15_tc2.h | 2 -
5 files changed, 166 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/lib/virt-v7.c
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 989bb72..56d0dd0 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -88,6 +88,13 @@ void v7_outer_cache_flush_range(u32 start, u32 end);
void v7_outer_cache_inval_range(u32 start, u32 end);
#ifdef CONFIG_ARMV7_VIRT
+
+#define HYP_ERR_NO_SEC_EXT 2
+#define HYP_ERR_NO_GIC_ADDRESS 3
+#define HYP_ERR_GIC_ADDRESS_ABOVE_4GB4
enum?
+
+int armv7_switch_nonsec(void);
+
/* defined in cpu/armv7/nonsec_virt.S */
void _nonsec_init(void);
#endif /* CONFIG_ARMV7_VIRT */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 8ad9f66..1570ad5 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -60,6 +60,8 @@ COBJS-y += reset.o
COBJS-y += cache.o
COBJS-y += cache-cp15.o
+COBJS-$(CONFIG_ARMV7_VIRT) += virt-v7.o
+
SRCS := $(GLSOBJS:.o=.S) $(GLCOBJS:.o=.c) \
$(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1b6e0ac..8251a89 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -34,6 +34,10 @@
#include asm/bootm.h
#include linux/compiler.h
+#ifdef CONFIG_ARMV7_VIRT
+#include asm/armv7.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
@@ -222,6 +226,22 @@ static void boot_prep_linux(bootm_headers_t *images)
printf(FDT and ATAGS support not compiled in - hanging\n);
hang();
}
+#ifdef CONFIG_ARMV7_VIRT
+ switch (armv7_switch_nonsec()) {
+ case 0:
+ debug(entered non-secure state\n);
+ break;
this is weird, why not have a define for the success case?
I still think the debug printing should be done inside
armv7_switch_nonsec instead, and you can just have it be a void();
+ case HYP_ERR_NO_SEC_EXT:
+ printf(HYP mode: Security extensions not implemented.\n);
+ break;
+ case HYP_ERR_NO_GIC_ADDRESS:
+ printf(HYP mode: could not determine GIC address.\n);
+ break;
+ case HYP_ERR_GIC_ADDRESS_ABOVE_4GB:
+ printf(HYP mode: PERIPHBASE is above 4 GB, cannot access
this.\n);
+ break;
+ }
+#endif
}
/* Subcommand: GO */
diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c
new file mode 100644
index 000..7876a77
--- /dev/null
+++ b/arch/arm/lib/virt-v7.c
@@ -0,0 +1,137 @@
+/*
+ * (C) Copyright 2013
+ * Andre Przywara, Linaro
+ *
+ * Routines to transition ARMv7 processors from secure into non-secure state
+ * needed to enable ARMv7 virtualization for current hypervisors
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is
[U-Boot] Flash not Erased
Hello, I am trying to compile my own U-Boot for microblaze. Version: U-Boot 2013.01-dirty (Jun 19 2013 - 16:26:51) microblazeel-xilinx-linux-gnu-gcc (crosstool-NG 1.15.3) 4.6.4 20120924 (prerelease) GNU ld (crosstool-NG 1.15.3) 2.22.90.20121010 I have demo where Flash access works fine. Verion: U-Boot 2012.10 (Feb 13 2013 - 20:16:43) microblazeel-xilinx-linux-gnu-gcc (crosstool-NG 1.15.3) 4.6.2 20111018 (prerelease) GNU ld (crosstool-NG 1.15.3) 2.21.53.20110813 When I use my own u-boot and try to write to flash I always get Flash not erased it seems to be a problem that my flash is x16 but recognized as x8. Are there any Config variables to set the mode to x16? Below are some snippets to show the behavior .. SHF-U-Boot saveenv Saving Environment to Flash... Protect off 44B4 ... 44B5 Un-Protecting sectors 90..90 in bank 1 fwc addr 44b4 cmd 50 50 8bit x 8 bit fwc addr 44b4 cmd 60 60 8bit x 8 bit fwc addr 44b4 cmd d0 d0 8bit x 8 bit fwc addr 44b4 cmd 70 70 8bit x 8 bit flash_is_busy: 0 fwc addr 44b4 cmd ff ff 8bit x 8 bit . done Un-Protected 1 sectors EXPORT table = bfc3b2cc, htab.size = 79, htab.filled = 13, size = 131068 Unsorted: n=13 0: bff80070 == ipaddr = 192.168.2.246 1: bff80084 == hostname = U-BOOT_BSP 2: bff800c0 == baudrate = 115200 3: bff80200 == bootdelay = 4 4: bff80228 == serverip = 192.168.0.1 5: bff80264 == ethaddr= 00:50:C2:2E:E1:0A 6: bff802f0 == fileaddr = BA00 7: bff80390 == bootfile = k7mmp/u-boot-s.bin 8: bff803e0 == ethact = Xelite.40e0 9: bff804d0 == gatewayip = 192.168.0.1 10: bff80584 == filesize = 353D0 11: bff80638 == mtdids = nor0=physmap-flash-0 12: bff8064c == mtdparts = mtdparts=physmap-flash-0:11M(fpga),256K(boot),128K(bootenv),128K(config),12M(image),0M(spare) Erasing Flash...Erase Flash from 0x44b4 to 0x44b5 in Bank # 1 flash_erase: erasing sectors 90 to 90 fwc addr 44b4 cmd 50 50 8bit x 8 bit fwc addr 44b4 cmd 20 20 8bit x 8 bit fwc addr 44b4 cmd d0 d0 8bit x 8 bit flash_is_busy: 1 ... flash_is_busy: 1 flash_is_busy: 0 fwc addr 44b4 cmd ff ff 8bit x 8 bit . done Erased 1 sectors Writing to Flash... flash_write_cfiword: 8-bit 0x92 fwc addr 4400 cmd 50 50 8bit x 8 bit fwc addr 4400 cmd 40 40 8bit x 8 bit flash_is_busy: 1 flash_is_busy: 0 fwc addr 44b4 cmd ff ff 8bit x 8 bit flash_write_cfiword: 8-bit 0xe8 Flash not Erased Protecting sectors 90..90 in bank 1 fwc addr 44b4 cmd 50 50 8bit x 8 bit fwc addr 44b4 cmd 60 60 8bit x 8 bit fwc addr 44b4 cmd 1 1 8bit x 8 bit fwc addr 44b4 cmd 70 70 8bit x 8 bit flash_is_busy: 0 fwc addr 44b4 cmd ff ff 8bit x 8 bit . done Protected 1 sectors Command failed, result=1SHF-U-Boot .. Now I try th co command to get more info .. SHF-U-Boot md 0xba00 ba00: b8b40008 8000 20a50100 e8c5... ba10: e8e50004 e9250008 20a5000c 0086..% ba20: 20e70003 90e70041 90e70041 8140... A...A.@. ba30: bc070018 c9055000 d9065000 214a0004.P...PJ! ba40: b810fff0 20e7 00844800 98082000... .H... .. ba50: SHF-U-Boot cp BA00 44B0 D4F5 Copy to Flash... flash_write_cfiword: 8-bit 0x08 fwc addr 4400 cmd 50 50 8bit x 8 bit fwc addr 4400 cmd 40 40 8bit x 8 bit flash_is_busy: 1 flash_is_busy: 0 fwc addr 44b0 cmd ff ff 8bit x 8 bit flash_write_cfiword: 8-bit 0x00 fwc addr 4400 cmd 50 50 8bit x 8 bit fwc addr 4400 cmd 40 40 8bit x 8 bit flash_is_busy: 1 flash_is_busy: 0 fwc addr 44b0 cmd ff ff 8bit x 8 bit flash_write_cfiword: 8-bit 0xb4 fwc addr 4400 cmd 50 50 8bit x 8 bit fwc addr 4400 cmd 40 40 8bit x 8 bit flash_is_busy: 1 flash_is_busy: 0 fwc addr 44b0 cmd ff ff 8bit x 8 bit flash_write_cfiword: 8-bit 0xb8 Flash not Erased Command failed, result=1SHF-U-Boot md 44B0 44b0: b4b4 44b00010: 44b00020: .Verion of working demo: U-Boot 2012.10 (Feb 13 2013 - 20:16:43) microblazeel-xilinx-linux-gnu-gcc (crosstool-NG 1.15.3) 4.6.2 20111018 (prerelease) GNU ld (crosstool-NG 1.15.3) 2.21.53.20110813 Version of non working: U-Boot 2013.01-dirty (Jun 19 2013 - 16:26:51) microblazeel-xilinx-linux-gnu-gcc (crosstool-NG 1.15.3) 4.6.4 20120924 (prerelease) GNU ld (crosstool-NG 1.15.3) 2.22.90.20121010...-- ..
Re: [U-Boot] [PATCH v2 3/7] ARM: add assembly routine to switch to non-secure state
On Thu, Jun 13, 2013 at 01:01:09PM +0200, Andre Przywara wrote: While actually switching to non-secure state is one thing, the more important part of this process is to make sure that we still super nit: not sure it's more important - it's just another thing we need to do. have full access to the interrupt controller (GIC). The GIC is fully aware of secure vs. non-secure state, some registers are banked, others may be configured to be accessible from secure state only. To be as generic as possible, we get the GIC memory mapped address based on the PERIPHBASE value in the CBAR register. Since this register is not architecturally defined, we check the MIDR before to be from an A15 or A7. For CPUs not having the CBAR or boards with wrong information herein we allow providing the base address as a configuration variable. With the GIC accessible, we: With the GIC accessible ? a) allow private interrupts to be delivered to the core (GICD_IGROUPR0 = 0x) b) enable the CPU interface (GICC_CTLR[0] = 1) c) set the priority filter to allow non-secure interrupts (GICC_PMR = 0xFF) After having switched to non-secure state, we also enable the non-secure GIC CPU interface, since this register is banked. Also we allow access to all coprocessor interfaces from non-secure state by writing the appropriate bits in the NSACR register. super nit 2: move this last paragraph above the non-secure stuff, so there's no confusion that this is done from secure mode. Since we need to call this routine also directly from the smp_pen later (where we don't have any stack), we can only use caller saved registers r0-r3 and r12 to not disturb the compiler. the compiler certainly does seem to get cranky when we disturb it ;) Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/nonsec_virt.S | 66 arch/arm/include/asm/armv7.h | 16 ++ arch/arm/include/asm/gic.h | 17 +++ 3 files changed, 99 insertions(+) create mode 100644 arch/arm/include/asm/gic.h diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index f5572f5..656d99b 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -23,6 +23,8 @@ */ #include config.h +#include asm/gic.h +#include asm/armv7.h /* the vector table for secure state */ _secure_vectors: @@ -52,3 +54,67 @@ _secure_monitor: movspc, lr @ return to non-secure SVC +#define lo(x) ((x) 0x) +#define hi(x) ((x) 16) + +/* + * Routine to switch a core to non-secure state. + * Initializes the GIC per-core interface, allows coprocessor access in + * non-secure modes and uses smc #0 to do the non-secure transition. + * To be called by smp_pen for secondary cores and directly for the BSP. + * For those two cases to work we must not use any stack and thus are + * limited to the caller saved registers r0-r3. you also use r12 (ip) ? Also, I think you can rewrite this comment to make it a little nicer. May I propose something along the lines of: /* * Switch a core to non-secure state. * * 1. initialize the GIC per-core interface * 2. allow coprocessor access in non-secure modes * 3. switch the cpu mode (by calling smc #0) * * Called from smp_pen by non-primary cores and directly by the BSP. * Do not assume that the stack is available and only use registers * r0-r3. * * PERIPHBASE is used to get the GIC address. This could be 40 bits long, * though, but we check this in C before calling this function. */ (I only propose this to match the high standard of these patches) + * PERIPHBASE is used to get the GIC address. This could be 40 bits long, + * though, but we check this in C before calling this function. + */ +.globl _nonsec_init +_nonsec_init: +#ifdef CONFIG_ARM_GIC_BASE_ADDRESS + ldr r2, =CONFIG_ARM_GIC_BASE_ADDRESS +#else + mrc p15, 4, r2, c15, c0, 0 @ read CBAR +#endif + add r3, r2, #GIC_DIST_OFFSET@ GIC dist i/f offset + mvn r1, #0 @ all bits to 1 + str r1, [r3, #GICD_IGROUPRn]@ allow private interrupts + + mrc p15, 0, r0, c0, c0, 0 @ read MIDR + bfc r0, #20, #4 @ mask out variant + bfc r0, #0, #4 @ and revision + + movwr1, #lo(MIDR_CORTEX_A7_R0P0 MIDR_PRIMARY_PART_MASK) in the git repo branch you pointed me to in the cover e-mail, this refers to MIDR_CORTEX_A6_R0P0 ? Forgot to push the last revision? + movtr1, #hi(MIDR_CORTEX_A7_R0P0 MIDR_PRIMARY_PART_MASK) + cmp r0, r1 @ check for Cortex-A7 + + orr r1, #(MIDR_CORTEX_A15_R0P0 0xf0) + cmpne r0, r1 @ check for Cortex-A15 + + movne r1, #GIC_CPU_OFFSET_A9 @ GIC CPU
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Tue, 18 Jun 2013 11:25:59 -0400, Tom Rini tr...@ti.com wrote: Hello, The following changes since commit 847e6693ccb529bf8346db62876f38f0c4e04ade: arm: pxa: config option for PXA270 turbo mode (2013-06-12 22:24:12 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to bf3b98a1886ef18d7e2e4f83fec17f6c8cc51eaf: arm: omap4: panda: Fix checkpatch on panda file (2013-06-18 10:43:30 -0400) Dan Murphy (5): arm: omap: Add check for fdtfile in the findfdt macro arm: omap5_uevm: Correct the console sys prompt for 5432 arm: dra7xx: Update the EXTRA_ENV_SETTINGS arm: omap4: panda: Add reading of the board revision arm: omap4: panda: Fix checkpatch on panda file Heiko Schocher (3): arm, am33xx: move rtc32k_enable() to common place arm, am335x: make mpu pll config configurable arm, am33xx: move uart soft reset code to common place arch/arm/cpu/armv7/am33xx/board.c| 40 ++ arch/arm/cpu/armv7/am33xx/clock_am33xx.c |9 ++- arch/arm/include/asm/arch-am33xx/sys_proto.h |4 + board/isee/igep0033/board.c | 40 +- board/phytec/pcm051/board.c | 39 +- board/ti/am335x/board.c | 39 +- board/ti/panda/panda.c | 104 +- board/ti/ti814x/evm.c| 35 + include/configs/am335x_evm.h |7 +- include/configs/dra7xx_evm.h |3 + include/configs/omap4_common.h |7 +- include/configs/omap5_common.h |9 ++- include/configs/omap5_uevm.h |4 +- 13 files changed, 164 insertions(+), 176 deletions(-) Thanks! Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] ARM: add SMP support for non-secure switch
On Thu, Jun 13, 2013 at 01:01:11PM +0200, Andre Przywara wrote:
Currently the non-secure switch is only done for the boot processor.
To enable full SMP support, we have to switch all secondary cores
into non-secure state also.
So we add an entry point for secondary CPUs coming out of low-power
state and make sure we put them into WFI again after having switched
to non-secure state.
For this we acknowledge and EOI the wake-up IPI, then go into WFI.
Once being kicked out of it later, we sanity check that the start
address has actually been changed (since another attempt to switch
to non-secure would block the core) and jump to the new address.
The actual CPU kick is done by sending an inter-processor interrupt
via the GIC to all CPU interfaces except the requesting processor.
The secondary cores will then setup their respective GIC CPU
interface.
The address secondary cores jump to is board specific, we provide
the value here for the Versatile Express board.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/cpu/armv7/nonsec_virt.S| 27 +++
arch/arm/include/asm/armv7.h| 1 +
arch/arm/lib/virt-v7.c | 19 ++-
include/configs/vexpress_ca15_tc2.h | 3 +++
4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S
b/arch/arm/cpu/armv7/nonsec_virt.S
index 656d99b..919f6e9 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -54,6 +54,33 @@ _secure_monitor:
movspc, lr @ return to non-secure SVC
+/*
+ * Secondary CPUs start here and call the code for the core specific parts
+ * of the non-secure and HYP mode transition. The GIC distributor specific
+ * code has already been executed by a C function before.
+ * Then they go back to wfi and wait to be woken up by the kernel again.
+ */
+.globl _smp_pen
+_smp_pen:
+ mrs r0, cpsr
+ orr r0, r0, #0xc0
+ msr cpsr, r0@ disable interrupts
+ ldr r1, =_start
+ mcr p15, 0, r1, c12, c0, 0 @ set VBAR
+
+ bl _nonsec_init
+
+ ldr r1, [r3, #0x0c] @ read GICD acknowledge
+ str r1, [r3, #0x10] @ write GICD EOI
+ adr r1, _smp_pen
+waitloop:
+ wfi
+ ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address
the name sysflags addr is a very vexpress specific thingy.
I think you need to call this something like SMP_SECONDARY_BOOT_ADDR or
whatever, which is more generic.
+ ldr r0, [r0]
+ cmp r0, r1 @ make sure we dont execute this code
+ beq waitloop@ again (due to a spurious wakeup)
+ mov pc, r0
+
#define lo(x) ((x) 0x)
#define hi(x) ((x) 16)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index 56d0dd0..04545b9 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -97,6 +97,7 @@ int armv7_switch_nonsec(void);
/* defined in cpu/armv7/nonsec_virt.S */
void _nonsec_init(void);
+void _smp_pen(void);
#endif /* CONFIG_ARMV7_VIRT */
#endif /* ! __ASSEMBLY__ */
diff --git a/arch/arm/lib/virt-v7.c b/arch/arm/lib/virt-v7.c
index 7876a77..6946e4d 100644
--- a/arch/arm/lib/virt-v7.c
+++ b/arch/arm/lib/virt-v7.c
@@ -95,6 +95,21 @@ static int get_gic_base_address(char **gicdptr)
#endif
}
+static void kick_secondary_cpus(char *gicdptr)
+{
+ unsigned int *sysflags;
again, I think the use of the name sysflags here is misunderstood.
+
+ sysflags = (void *)CONFIG_SYSFLAGS_ADDR;
+#ifdef CONFIG_SYSFLAGS_NEED_CLEAR_BITS
+ sysflags[1] = (unsigned)-1;
this feels like we're wrapping some vexpress-logic into some
pseudo-generic logic here. It feels like there should be a function
provided by the board code, that we simply call.
void set_board_smp_boot_addr(unsigned long addr);
+#endif
+ *sysflags = (uintptr_t)_smp_pen;
+ dmb();
+
+ /* now kick all CPUs (expect this one) by writing to GICD_SGIR */
s/expect/except/
+ writel(1U 24, gicdptr[GICD_SGIR]);
+}
+
int armv7_switch_nonsec(void)
{
unsigned int reg, ret;
@@ -130,7 +145,9 @@ int armv7_switch_nonsec(void)
for (i = 0; i = itlinesnr; i++)
writel((unsigned)-1, gicdptr[GICD_IGROUPRn + 4 * i]);
- /* call the non-sec switching code on this CPU */
+ kick_secondary_cpus(gicdptr);
+
+ /* call the non-sec switching code on this CPU also */
_nonsec_init();
return 0;
diff --git a/include/configs/vexpress_ca15_tc2.h
b/include/configs/vexpress_ca15_tc2.h
index 4f425ac..ade9e5b 100644
--- a/include/configs/vexpress_ca15_tc2.h
+++ b/include/configs/vexpress_ca15_tc2.h
@@ -31,4 +31,7 @@
#include vexpress_common.h
#define CONFIG_BOOTP_VCI_STRING
Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode
On Thu, Jun 13, 2013 at 01:01:12PM +0200, Andre Przywara wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/nonsec_virt.S | 31 --- arch/arm/include/asm/armv7.h | 7 +-- arch/arm/lib/bootm.c | 14 ++ arch/arm/lib/virt-v7.c | 27 ++- 4 files changed, 65 insertions(+), 14 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index 919f6e9..950da6f 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYP mode * * Copyright (c) 2013Andre Przywara andre.przyw...@linaro.org * @@ -26,14 +26,14 @@ #include asm/gic.h #include asm/armv7.h -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _secure_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 .word 0 /* pad */ @@ -50,10 +50,23 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW, FW bits + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp r0, #(1 CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVC instruction + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value Why not just do load the address of _secure_vectors directly? I think it makes it more clear what happens. + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR + movspc, lr @ return to non-secure SVC +_hyp_trap: + .byte 0x00, 0xe3, 0x0e, 0xe1@ mrs lr, elr_hyp Again, why not just add the necessary .arch_extension or assembler directive in the makefile and use the instructions directly. The only reason I would see for performing this obscurity would be to support really old compilers, which I doubt we fill for future boards? + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -69,6 +82,7 @@ _smp_pen: mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + bl _hyp_init ldr r1, [r3, #0x0c] @ read GICD acknowledge str r1, [r3, #0x10] @ write GICD EOI @@ -145,3 +159,14 @@ _nonsec_init: str r1, [r2]@ allow private interrupts bx lr + +.globl _hyp_init +_hyp_init: nit: the naming here is a little misleading for someone not knowing what's going on. You're not really initializing the mode, but switching to it: _switch_to_hyp: ??? + mov r2, lr + mov r3, sp @ save SVC copy of LR and SP + isb I don't think this isb is necessary. + .byte 0x70, 0x00, 0x40, 0xe1@ hvc #0 again, this is really funky. If it's really necessary, can we please have a define somewhere so you can just do HVC(0) instead? + mov sp, r3 + mov lr, r2 @ fix HYP mode banked LR and SP nit: s/fix HYP mode/restore S-SVC mode/ + + bx lr diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index 04545b9..8c3a85e 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -89,15 +89,18 @@ void v7_outer_cache_inval_range(u32 start, u32
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
Dear Otavio Salvador,
On Wed, Jun 19, 2013 at 10:44 AM, Axel Lin axel@ingics.com wrote:
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0, regs-gpiodata[DATA_REG_ADDR(gpio)]);
return 0;
}
writel(value gpio, regs-gpiodata[DATA_REG_ADDR(gpio)]);
Should do no? This would avoid the if block.
No, you need clrbits_le32() to unset the GPIO
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] gpio: omap_gpio: Remove check_gpio() function
check_gpio() and gpio_is_valid() are both used to check if a gpio is valid or
not. It looks pointless to have both function because we can just call
gpio_is_valid() instead of check_gpio(). Thus remove check_gpio() function.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/gpio/omap_gpio.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index a30d7f0..221acc6 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -58,15 +58,6 @@ int gpio_is_valid(int gpio)
return (gpio = 0) (gpio 192);
}
-static int check_gpio(int gpio)
-{
- if (!gpio_is_valid(gpio)) {
- printf(ERROR : check_gpio: invalid GPIO %d\n, gpio);
- return -1;
- }
- return 0;
-}
-
static void _set_gpio_direction(const struct gpio_bank *bank, int gpio,
int is_input)
{
@@ -142,7 +133,7 @@ int gpio_set_value(unsigned gpio, int value)
{
const struct gpio_bank *bank;
- if (check_gpio(gpio) 0)
+ if (!gpio_is_valid(gpio))
return -1;
bank = get_gpio_bank(gpio);
_set_gpio_dataout(bank, get_gpio_index(gpio), value);
@@ -159,7 +150,7 @@ int gpio_get_value(unsigned gpio)
void *reg;
int input;
- if (check_gpio(gpio) 0)
+ if (!gpio_is_valid(gpio))
return -1;
bank = get_gpio_bank(gpio);
reg = bank-base;
@@ -191,7 +182,7 @@ int gpio_direction_input(unsigned gpio)
{
const struct gpio_bank *bank;
- if (check_gpio(gpio) 0)
+ if (!gpio_is_valid(gpio))
return -1;
bank = get_gpio_bank(gpio);
@@ -207,7 +198,7 @@ int gpio_direction_output(unsigned gpio, int value)
{
const struct gpio_bank *bank;
- if (check_gpio(gpio) 0)
+ if (!gpio_is_valid(gpio))
return -1;
bank = get_gpio_bank(gpio);
@@ -224,7 +215,7 @@ int gpio_direction_output(unsigned gpio, int value)
*/
int gpio_request(unsigned gpio, const char *label)
{
- if (check_gpio(gpio) 0)
+ if (!gpio_is_valid(gpio))
return -1;
return 0;
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merge Window close date
Hi Albert. To sum up things (anyone correct me as needed): It is very useful list of rules and cleared my questions about the MW. Thanks a lot! Best Regards, Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merge Window close date
Hi Wolfgang. In message 20130619105426.7444.aa925...@jp.panasonic.com you wrote: Especailly after reading this http://thread.gmane.org/gmane.linux.network/104943/focus=104951 Maybe I became a little nervous about the MW. I'm not sure what you mean here? What I tried to say is: http://thread.gmane.org/gmane.linux.network/104943/focus=104951 is linked from the U-Boot Release Cycle page. I read throught it. Linus complained so severly about sending patches out of MW. I was not sure U-Boot maintainers are harsh as well, but I tried to be as careful as possible not to post my patch when I shoudn't. I believed the Release Cycle page was showing the current MW status. That's why I often checked this page. At first, I thoght patches shouldn't be sent out of the MW, except bug fixes or so. But it was my misunderstading. Albert sent the very useful list of the MW rules. According to it, patches can be sent any time, even though they may not included the next release. Now I could understand the MW well with help of you and Albert. Thanks a lot! Best Regards, Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 0/3] Introduce Samsung's new board Trats2
Tested-by: Jaehoon Chung jh80.ch...@samsung.com Best Regards, Jaehoon Chung On 06/18/2013 04:00 PM, Jaehoon Chung wrote: Hi Piotr, I tested your patches on trats2 board. I found the below log message..If i missed some patch, let me know. Board PMIC init Can't find PMIC:MAX77686_PMIC What's this log? Best Regards, Jaehoon Chung On 05/24/2013 05:23 PM, Piotr Wilczek wrote: This patchset add support for a new Samsung board Trats2. Multi I2C file is update to support more buses. Battery support is added for Trats2. This patchset depends on: http://patchwork.ozlabs.org/patch/246101/ http://patchwork.ozlabs.org/patch/246100/ http://patchwork.ozlabs.org/patch/245311/ http://patchwork.ozlabs.org/patch/245307/ http://patchwork.ozlabs.org/patch/245306/ Changes in v3: - add Maintainer entry - changed T-flash detect pin to GPX3[3] - removed MMC_ASYNC - use only software i2c Changes in v2: - removed lcd callback in panel_info - changed i2c from hardware to software - use max77693 multifunction pmic Piotr Wilczek (3): power:battery: add battery support for Trats2 board i2c:multi_i2c: add new macros I2C_7 and I2C_8 samsung: trats2: add support for new board Trats2 MAINTAINERS|4 + board/samsung/common/multi_i2c.c | 33 +++ board/samsung/trats2/Makefile | 50 board/samsung/trats2/trats2.c | 529 boards.cfg |1 + drivers/power/battery/Makefile |1 + drivers/power/battery/bat_trats2.c | 81 ++ include/configs/trats2.h | 326 ++ 8 files changed, 1025 insertions(+) create mode 100644 board/samsung/trats2/Makefile create mode 100644 board/samsung/trats2/trats2.c create mode 100644 drivers/power/battery/bat_trats2.c create mode 100644 include/configs/trats2.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 17/21] arm: Implement the 'fake' go command
Implement this feature on ARM for tracing.
It would be nice to have generic bootm support so that it is easily
implemented on any arch.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Revert to using 'images' instead of 'image' in boot_jump_linux()
Changes in v2: None
arch/arm/lib/bootm.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1b6e0ac..b22fbc9 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -68,12 +68,19 @@ void arch_lmb_reserve(struct lmb *lmb)
gd-bd-bi_dram[0].start + gd-bd-bi_dram[0].size - sp);
}
-static void announce_and_cleanup(void)
+/**
+ * announce_and_cleanup() - Print message and prepare for kernel boot
+ *
+ * @fake: non-zero to do everything except actually boot
+ */
+static void announce_and_cleanup(int fake)
{
- printf(\nStarting kernel ...\n\n);
+ printf(\nStarting kernel ...%s\n\n, fake ?
+ (fake run for tracing) : );
bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, start_kernel);
#ifdef CONFIG_BOOTSTAGE_FDT
- bootstage_fdt_add_report();
+ if (flag == BOOTM_STATE_OS_FAKE_GO)
+ bootstage_fdt_add_report();
#endif
#ifdef CONFIG_BOOTSTAGE_REPORT
bootstage_report();
@@ -225,12 +232,13 @@ static void boot_prep_linux(bootm_headers_t *images)
}
/* Subcommand: GO */
-static void boot_jump_linux(bootm_headers_t *images)
+static void boot_jump_linux(bootm_headers_t *images, int flag)
{
unsigned long machid = gd-bd-bi_arch_number;
char *s;
void (*kernel_entry)(int zero, int arch, uint params);
unsigned long r2;
+ int fake = (flag BOOTM_STATE_OS_FAKE_GO);
kernel_entry = (void (*)(int, int, uint))images-ep;
@@ -243,14 +251,15 @@ static void boot_jump_linux(bootm_headers_t *images)
debug(## Transferring control to Linux (at address %08lx) \
...\n, (ulong) kernel_entry);
bootstage_mark(BOOTSTAGE_ID_RUN_OS);
- announce_and_cleanup();
+ announce_and_cleanup(fake);
if (IMAGE_ENABLE_OF_LIBFDT images-ft_len)
r2 = (unsigned long)images-ft_addr;
else
r2 = gd-bd-bi_boot_params;
- kernel_entry(0, machid, r2);
+ if (!fake)
+ kernel_entry(0, machid, r2);
}
/* Main Entry point for arm bootm implementation
@@ -270,13 +279,13 @@ int do_bootm_linux(int flag, int argc, char *argv[],
bootm_headers_t *images)
return 0;
}
- if (flag BOOTM_STATE_OS_GO) {
- boot_jump_linux(images);
+ if (flag (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
+ boot_jump_linux(images, flag);
return 0;
}
boot_prep_linux(images);
- boot_jump_linux(images);
+ boot_jump_linux(images, flag);
return 0;
}
--
1.8.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/21] arm: Implement the 'fake' go command
Hi Albert, On Tue, Jun 11, 2013 at 2:36 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Simon, On Tue, 11 Jun 2013 14:17:42 -0700, Simon Glass s...@chromium.org wrote: Hi Albert, On Tue, Jun 11, 2013 at 1:21 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Simon, On Tue, 11 Jun 2013 13:02:56 -0700, Simon Glass s...@chromium.org wrote: Hi Albert, On Tue, Jun 11, 2013 at 12:59 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Simon, On Tue, 11 Jun 2013 11:14:49 -0700, Simon Glass s...@chromium.org wrote: Implement this feature on ARM for tracing. It would be nice to have generic bootm support so that it is easily implemented on any arch. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None arch/arm/lib/bootm.c | 33 + 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 1b6e0ac..28fba19 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -225,14 +232,15 @@ static void boot_prep_linux(bootm_headers_t *images) } /* Subcommand: GO */ -static void boot_jump_linux(bootm_headers_t *images) +static void boot_jump_linux(bootm_headers_t *image, int flag) What's the rationale of the s/images/image/ ? Just that the function only accesses a single image, so I felt it was a misnomer. I wonder if the naming was not initially chosen to remind readers that this single image file may actually contain several images (kernel+initrd, for instance. Ah yes, that could be it :-) Shall I change it back? I'd personally prefer that you keep it plural as it was, yes. OK I sent a v3 patch for this one. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpio: Question about gpio_set_value() implementation in spear_gpio.c
On 6/19/2013 7:14 PM, Axel Lin wrote:
Current code looks strange because no matter the value argument is 0 or 1
it always calls
writel(1 gpio,regs-gpiodata[DATA_REG_ADDR(gpio)]);
And then gpio_get_value() always return 1.
I'm wondering if it needs to be fixed, something like below change:
diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c
index d3c728e..8878608 100644
--- a/drivers/gpio/spear_gpio.c
+++ b/drivers/gpio/spear_gpio.c
@@ -52,7 +52,10 @@ int gpio_set_value(unsigned gpio, int value)
{
struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE;
- writel(1 gpio,regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ if (value)
+ writel(1 gpio,regs-gpiodata[DATA_REG_ADDR(gpio)]);
+ else
+ writel(0,regs-gpiodata[DATA_REG_ADDR(gpio)]);
Yes, this is the right way. It was a blunder. I am wondering no one ever
tried to set a ZERO on any GPIO..
Thanks for pointing out
Regards
Vipin
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Bring in new I2C framework
Hello Simon, Am 20.06.2013 00:07, schrieb Simon Glass: Hi Heiko, On Sun, May 19, 2013 at 11:13 PM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Hi Simon, -Original Message- From: s...@google.com mailto:s...@google.com [mailto:s...@google.com mailto:s...@google.com] On Behalf Of Simon Glass Sent: Saturday, May 18, 2013 7:41 PM To: Piotr Wilczek Cc: Heiko Schocher; U-Boot Mailing List; Dirk Eibach; Stefan Roese; Holger Brunck; Mike Frysinger; Stephen Warren; Minkyu Kang Subject: Re: [PATCH v3 0/9] Bring in new I2C framework Hi Piotr, On Fri, May 17, 2013 at 6:17 AM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Dear Heiko, -Original Message- From: Heiko Schocher [mailto:h...@denx.de mailto:h...@denx.de] Sent: Saturday, May 04, 2013 2:02 PM To: u-boot@lists.denx.de mailto:u-boot@lists.denx.de Cc: Heiko Schocher; Dirk Eibach; Stefan Roese; Simon Glass; Piotr Wilczek; Holger Brunck; Mike Frysinger; Stephen Warren Subject: [PATCH v3 0/9] Bring in new I2C framework It seems the timing is coming, to bring this finally in mainline and move boards over to the new i2c framework. Changes for v3 series: - Compiler collects the used i2c adapters in _u_boot_list_i2c, so no need for defining the used i2c adpaters in the board config file. - drop CONFIG_SYS_NUM_I2C_ADAPTERS and CONFIG_SYS_I2C_ADAPTERS - Some adaptions for the keymile boards, so we can drop CONFIG_I2C_MUX completely - add ppc4xx_i2c driver, ported from Dirk Eibach Serie compiles clean on arm and powerpc Ported i2c drivers: soft_i2c : from me, tested on some arm and powerpc boards fsl_i2c : from me, only compile tested tegra_i2c : ported from Simon Glass ppc4xx_i2c: adapted from Dirk Eibach dirk.eib...@gdsys.cc tested on (which board?) with 4 soft_i2c drivers and one ppc4x_i2c driver. Cc: Dirk Eibach dirk.eib...@gdsys.cc Cc: Stefan Roese s...@denx.de mailto:s...@denx.de Cc: Simon Glass s...@chromium.org mailto:s...@chromium.org Cc: Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com Cc: Holger Brunck holger.bru...@keymile.com mailto:holger.bru...@keymile.com Cc: Mike Frysinger vap...@gentoo.org mailto:vap...@gentoo.org Cc: Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org I ported s3c24x0_i2c driver and tested this framework on Samsung tree on Trats2 board. Please can you send a patch for this port? I posted that patch and some others with series introducing Trsts2, where I want to use this framework. I'm sorry I didn't mention it in my first mail. http://patchwork.ozlabs.org/patch/244645/ http://patchwork.ozlabs.org/patch/244644/ . http://patchwork.ozlabs.org/patch/244638/ http://patchwork.ozlabs.org/patch/244637/ http://patchwork.ozlabs.org/patch/244640/ http://patchwork.ozlabs.org/patch/244636/ Hups, missed this patches ... What is the status of this series now please? I heared nothing negatives for the new i2c multibus framework, so I plan to merge it into mainline, if the next merge widow is open. So, the best for above patches would be, If I delegate them to me, and apply them, when merging the new i2c multibus support ... @Minkyu: Is this OK for you? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, am33xx: move s_init to a common place
Hello Tom, Am 14.06.2013 16:58, schrieb Tom Rini: On Fri, Jun 14, 2013 at 07:59:26AM +0200, Heiko Schocher wrote: Hello Tom, Am 13.06.2013 17:53, schrieb Tom Rini: On Thu, Jun 13, 2013 at 05:53:17AM +0200, Heiko Schocher wrote: move s_init from every board code to a common place. Signed-off-by: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com Cc: Matt Porter mpor...@ti.com Cc: Lars Poeschel poesc...@lemonage.de Cc: Tom Rini tr...@ti.com Cc: Enric Balletbo i Serra eballe...@iseebcn.com --- This patch is based on the following patches: - [U-Boot,v2] arm, am33xx: move rtc32k_enable() to common place http://patchwork.ozlabs.org/patch/248908/ - [U-Boot] arm, am33xx: move uart soft reset code to common place http://patchwork.ozlabs.org/patch/248508/ These two apply best to u-boot-ti, and with them this patch doesn't apply cleanly. Please sort that out. I based my patches on u-boot ... I look at this .. The following adds moving ti814x_evm into the mix and I've sent Matt some binaries to give a whirl to test on the board: [...] /* * Basic board specific setup. Pinmux has been handled already. Please fold into v2 Signed-off-by: Tom Rini tr...@ti.com Ok, thanks! There's a minor bug in what I posted, however. ti814x needs timer_init called _before_ pll_init() as setting the sata clocks (which are shared with other periphrals that we do enable right now) needs udelay(50) to settle as we go along. That also needs to be commented in the code as I had to think about it for a bit to recall exactly what was going on. Do you have an update here for me? BTW: I just realized that I have on one of the three boards a problem, that in spl code calling the rtc32k_enable() crashes ... which votes against moving this to a common place ... I haveno real idea why ... did you heard from such a behaviour? Is there some am335x soc, which differs from the others? You aren't using a different clock crystal rate than the reference platforms, are you? I know that's a problem that needs solving still. I am prospecting, whats going on here ... but have no real idea, why it is not possible to write this registers ... if writing this registers, cpu hang ... But I want to have a common function here ... maybe it is OK to make the rtc32k_enable() call configurable through a define? Saying CONFIG_SPL_AM33XX_DO_NOT_ENABLE_RTC32K and document in the u-boot README this define, and why it is necessary? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] net2big_v2: initialize fan and LEDs at startup
-Original Message- From: Simon Guinot [mailto:simon.gui...@sequanux.org] Sent: 18 June 2013 18:45 To: Prafulla Wadaskar Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: [PATCH v2 0/3] net2big_v2: initialize fan and LEDs at startup This patch series allows to initialize the fan and the LEDs found on the net2big_v2. Changes in v2: - Add Prafulla's Acked-by to patch net2big_v2: initialize I2C fan at startup - Rename gpio-ext into cpld-gpio-bus and adjust code and comments accordingly. Simon Guinot (3): net2big_v2: initialize I2C fan at startup LaCie/common: add support for the CPLD GPIO bus net2big_v2: initialize LEDs at startup board/LaCie/common/cpld-gpio-bus.c | 50 board/LaCie/common/cpld-gpio-bus.h | 24 ++ board/LaCie/net2big_v2/Makefile |3 + board/LaCie/net2big_v2/net2big_v2.c | 154 +-- board/LaCie/net2big_v2/net2big_v2.h |5 ++ include/configs/lacie_kw.h |9 +- 6 files changed, 236 insertions(+), 9 deletions(-) create mode 100644 board/LaCie/common/cpld-gpio-bus.c create mode 100644 board/LaCie/common/cpld-gpio-bus.h Acked-by: Prafulla Wadaskar prafu...@marvell.com For entire patch series. Will be pulled soon. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: omap_gpio: Remove check_gpio() function
Hi Axel, On 06/20/2013 04:03 AM, Axel Lin wrote: check_gpio() and gpio_is_valid() are both used to check if a gpio is valid or not. It looks pointless to have both function because we can just call gpio_is_valid() instead of check_gpio(). Thus remove check_gpio() function. I don't see the benefit in this patch. The functions clearly exist for different reasons: gpio_is_valid() is part of the gpio api, while check_gpio() exists to attach an error message to a failed validity check without causing code duplication all over omap_gpio.c. Essentially what you are doing is removing a helpful error message. -- Regards, Nikita. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] xilinx: move microblaze-generic .dts to standard location
On 06/19/2013 10:36 PM, Simon Glass wrote: On Mon, Jun 10, 2013 at 4:16 PM, Stephen Warren swar...@wwwdotorg.orgwrote: From: Stephen Warren swar...@nvidia.com Aside from microblaze, all other SoCs/boards/vendors store their DT files in board/$vendor/dts/$soc-$board.dts. Move microblaze-generic.dts to this location for consistency. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Simon Glass s...@chromium.org Acked-by: Michal Simek mon...@monstr.eu M -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand onfi 8bit/16bit bus support
On 06/19/2013 07:17 PM, Scott Wood wrote: On 06/19/2013 08:40:19 AM, Michal Simek wrote: Hi Scott, On 05/09/2013 11:37 PM, Scott Wood wrote: On 05/06/2013 11:53:52 AM, Michal Simek wrote: Hi guys, Zynq supports 8 and 16bit ONFI nand flashes. We can count number of connected pins and from that we know if 8bit or 16bit nand flash is used. I have looked at the code and contains ONFI detection with correct detection of bus width + checking later. Why also not setup proper chip-options for NAND_BUSWIDTH_16? Not sure how others but if driver expect just ONFI devices and support 8 and 16bit options why not just to setup chip options based on information from ONFI or not check that (busw != (chip-options NAND_BUSWIDTH_16)) for onfi case. This is fixed in current Linux, with NAND_BUSWIDTH_AUTO. There was a patchset to merge in recent Linux MTD code a while back, but an expected respin didn't come. I'll try to fix it up when I process this merge window's patches. Have you done this change? I have grepped the latest version and I can't see it there. MTD from 3.7.1 (which was what was current when the patch was posted months ago) was merged in. It looks like NAND_BUSWIDTH_AUTO was added in 3.8. We can do another MTD update in the next merge window, which would pick this up. Or if you'd like to submit a patch that just fixes this problem (in the same way as in Linux, so it doesn't conflict too badly when we do the merge), it could be applied now as a bugfix. Ah ok. From my point of view it is not bug fix but new features and should go to the u-boot in proper merge window. No problem to wait just wanted to get update on this to be able to better plan our work. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu, nand: before write a buffer to nand, erase the nand sectors
Hello Scott,
Am 18.06.2013 02:51, schrieb Scott Wood:
On 06/17/2013 12:01:01 AM, Heiko Schocher wrote:
before writing the received buffer to nand, erase the nand
sectors. If not doing this, nand write fails. See for
more info here:
http://lists.denx.de/pipermail/u-boot/2013-June/156361.html
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Scott Wood scottw...@freescale.com
Cc: Pantelis Antoniou pa...@antoniou-consulting.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- use opts.spread as Scott Wood suggested
drivers/dfu/dfu_nand.c | 17 +++--
1 Datei geändert, 15 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 7dc89b2..93db9bd 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -63,12 +63,25 @@ static int nand_block_op(enum dfu_nand_op op,
struct dfu_entity *dfu,
nand = nand_info[nand_curr_device];
-if (op == DFU_OP_READ)
+if (op == DFU_OP_READ) {
ret = nand_read_skip_bad(nand, start, count, actual,
lim, buf);
-else
+} else {
+nand_erase_options_t opts;
+
+memset(opts, 0, sizeof(opts));
+opts.offset = start;
+opts.length = count;
+opts.spread = 1;
+opts.quiet = 1;
+/* first erase */
+ret = nand_erase_opts(nand, opts);
+if (ret)
+return ret;
+/* then write */
ret = nand_write_skip_bad(nand, start, count, actual,
lim, buf, 0);
BTW, I notice you are currently using the limit functionality of
nand_read/write_skip_bad... opts.spread currently does not have this
support (as I noted before), which means that if there's an error you'd
erase too much and then refuse to write.
Maybe we need an opts.limit?
Yes, I think so ... whats with the following proposal:
diff --git a/drivers/mtd/nand/nand_util.c b/drivers/mtd/nand/nand_util.c
index d81972c..b877c7d 100644
--- a/drivers/mtd/nand/nand_util.c
+++ b/drivers/mtd/nand/nand_util.c
@@ -120,6 +120,10 @@ int nand_erase_opts(nand_info_t *meminfo, const
nand_erase_options_t *opts)
WATCHDOG_RESET();
+ if ((opts-limit) (erase.addr opts-limit)) {
+ puts(Size of write exceeds partition or device
limit\n);
+ return -EFBIG;
+ }
if (!opts-scrub bbtest) {
int ret = mtd_block_isbad(meminfo, erase.addr);
if (ret 0) {
diff --git a/include/nand.h b/include/nand.h
index 26190e4..d799df3 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -125,6 +125,8 @@ struct nand_erase_options {
/* Don't include skipped bad blocks in size to be erased */
int spread;
+ /* maximum size that actual may be in order to not exceed the buf */
+ loff_t limit;
};
typedef struct nand_erase_options nand_erase_options_t;
I checked for all calls from nand_erase_opts, that the nand_erase_options_t
parameters are initialized with 0 ... so this patch should not change
current behaviour.
Should I do this in a seperate patch, or add it to the dfu, nand:
before write a buffer to nand, erase the nand sectors patch, so it adds
no dead code ...
adjust_size_for_badblocks, OTOH, is probably the opposite of what you
wanted -- it subtracts from the size in order to get the number of good
blocks within an interval, rather than adding the number of bad blocks
to turn a data size into an interval. It's meant to produce an input
to be used with skipping/spreading operations.
Yes, thats not what I wanted ...
Which makes me think we have a bug in cmd_nand.c -- we should be
setting .spread in erase cases where we call adjust_size_for_badblocks.
Yes, seems so ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/3] net2big_v2: initialize fan and LEDs at startup
-Original Message- From: Prafulla Wadaskar Sent: 20 June 2013 10:46 To: 'Simon Guinot' Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: RE: [PATCH v2 0/3] net2big_v2: initialize fan and LEDs at startup -Original Message- From: Simon Guinot [mailto:simon.gui...@sequanux.org] Sent: 18 June 2013 18:45 To: Prafulla Wadaskar Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: [PATCH v2 0/3] net2big_v2: initialize fan and LEDs at startup This patch series allows to initialize the fan and the LEDs found on the net2big_v2. Changes in v2: - Add Prafulla's Acked-by to patch net2big_v2: initialize I2C fan at startup - Rename gpio-ext into cpld-gpio-bus and adjust code and comments accordingly. Simon Guinot (3): net2big_v2: initialize I2C fan at startup LaCie/common: add support for the CPLD GPIO bus net2big_v2: initialize LEDs at startup board/LaCie/common/cpld-gpio-bus.c | 50 board/LaCie/common/cpld-gpio-bus.h | 24 ++ board/LaCie/net2big_v2/Makefile |3 + board/LaCie/net2big_v2/net2big_v2.c | 154 +-- board/LaCie/net2big_v2/net2big_v2.h |5 ++ include/configs/lacie_kw.h |9 +- 6 files changed, 236 insertions(+), 9 deletions(-) create mode 100644 board/LaCie/common/cpld-gpio- bus.c create mode 100644 board/LaCie/common/cpld-gpio- bus.h Acked-by: Prafulla Wadaskar prafu...@marvell.com For entire patch series. Will be pulled soon. Applied to u-boot-marvell.git master branch Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request for u-boot-marvell.git
The following changes since commit c2543a21df335484fa86bd652b5564d0ca90d5f6: Albert ARIBAUD (1): Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' are available in the git repository at: u-boot-marvell.git master branch. Simon Guinot (3): net2big_v2: initialize I2C fan at startup LaCie/common: add support for the CPLD GPIO bus net2big_v2: initialize LEDs at startup board/LaCie/common/cpld-gpio-bus.c | 50 +++ board/LaCie/common/cpld-gpio-bus.h | 24 ++ board/LaCie/net2big_v2/Makefile |3 + board/LaCie/net2big_v2/net2big_v2.c | 154 +-- board/LaCie/net2big_v2/net2big_v2.h |5 + include/configs/lacie_kw.h |9 ++- 6 files changed, 236 insertions(+), 9 deletions(-) create mode 100644 board/LaCie/common/cpld-gpio-bus.c create mode 100644 board/LaCie/common/cpld-gpio-bus. Regards... Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Bring in new I2C framework
Dear Heiko, On 20/06/13 12:38, Heiko Schocher wrote: Hello Simon, Am 20.06.2013 00:07, schrieb Simon Glass: Hi Heiko, On Sun, May 19, 2013 at 11:13 PM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Hi Simon, -Original Message- From: s...@google.com mailto:s...@google.com [mailto:s...@google.com mailto:s...@google.com] On Behalf Of Simon Glass Sent: Saturday, May 18, 2013 7:41 PM To: Piotr Wilczek Cc: Heiko Schocher; U-Boot Mailing List; Dirk Eibach; Stefan Roese; Holger Brunck; Mike Frysinger; Stephen Warren; Minkyu Kang Subject: Re: [PATCH v3 0/9] Bring in new I2C framework Hi Piotr, On Fri, May 17, 2013 at 6:17 AM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Dear Heiko, -Original Message- From: Heiko Schocher [mailto:h...@denx.de mailto:h...@denx.de] Sent: Saturday, May 04, 2013 2:02 PM To: u-boot@lists.denx.de mailto:u-boot@lists.denx.de Cc: Heiko Schocher; Dirk Eibach; Stefan Roese; Simon Glass; Piotr Wilczek; Holger Brunck; Mike Frysinger; Stephen Warren Subject: [PATCH v3 0/9] Bring in new I2C framework It seems the timing is coming, to bring this finally in mainline and move boards over to the new i2c framework. Changes for v3 series: - Compiler collects the used i2c adapters in _u_boot_list_i2c, so no need for defining the used i2c adpaters in the board config file. - drop CONFIG_SYS_NUM_I2C_ADAPTERS and CONFIG_SYS_I2C_ADAPTERS - Some adaptions for the keymile boards, so we can drop CONFIG_I2C_MUX completely - add ppc4xx_i2c driver, ported from Dirk Eibach Serie compiles clean on arm and powerpc Ported i2c drivers: soft_i2c : from me, tested on some arm and powerpc boards fsl_i2c : from me, only compile tested tegra_i2c : ported from Simon Glass ppc4xx_i2c: adapted from Dirk Eibach dirk.eib...@gdsys.cc tested on (which board?) with 4 soft_i2c drivers and one ppc4x_i2c driver. Cc: Dirk Eibach dirk.eib...@gdsys.cc Cc: Stefan Roese s...@denx.de mailto:s...@denx.de Cc: Simon Glass s...@chromium.org mailto:s...@chromium.org Cc: Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com Cc: Holger Brunck holger.bru...@keymile.com mailto:holger.bru...@keymile.com Cc: Mike Frysinger vap...@gentoo.org mailto:vap...@gentoo.org Cc: Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org I ported s3c24x0_i2c driver and tested this framework on Samsung tree on Trats2 board. Please can you send a patch for this port? I posted that patch and some others with series introducing Trsts2, where I want to use this framework. I'm sorry I didn't mention it in my first mail. http://patchwork.ozlabs.org/patch/244645/ http://patchwork.ozlabs.org/patch/244644/ . http://patchwork.ozlabs.org/patch/244638/ http://patchwork.ozlabs.org/patch/244637/ http://patchwork.ozlabs.org/patch/244640/ http://patchwork.ozlabs.org/patch/244636/ Hups, missed this patches ... What is the status of this series now please? I heared nothing negatives for the new i2c multibus framework, so I plan to merge it into mainline, if the next merge widow is open. So, the best for above patches would be, If I delegate them to me, and apply them, when merging the new i2c multibus support ... @Minkyu: Is this OK for you? OK.. please pick patches. bye, Heiko Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/9] Bring in new I2C framework
Dear All, -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, June 20, 2013 5:38 AM To: Simon Glass Cc: Piotr Wilczek; U-Boot Mailing List; Dirk Eibach; Stefan Roese; Holger Brunck; Mike Frysinger; Stephen Warren; Minkyu Kang Subject: Re: [PATCH v3 0/9] Bring in new I2C framework Hello Simon, Am 20.06.2013 00:07, schrieb Simon Glass: Hi Heiko, On Sun, May 19, 2013 at 11:13 PM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Hi Simon, -Original Message- From: s...@google.com mailto:s...@google.com [mailto:s...@google.com mailto:s...@google.com] On Behalf Of Simon Glass Sent: Saturday, May 18, 2013 7:41 PM To: Piotr Wilczek Cc: Heiko Schocher; U-Boot Mailing List; Dirk Eibach; Stefan Roese; Holger Brunck; Mike Frysinger; Stephen Warren; Minkyu Kang Subject: Re: [PATCH v3 0/9] Bring in new I2C framework Hi Piotr, On Fri, May 17, 2013 at 6:17 AM, Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com wrote: Dear Heiko, -Original Message- From: Heiko Schocher [mailto:h...@denx.de mailto:h...@denx.de] Sent: Saturday, May 04, 2013 2:02 PM To: u-boot@lists.denx.de mailto:u-boot@lists.denx.de Cc: Heiko Schocher; Dirk Eibach; Stefan Roese; Simon Glass; Piotr Wilczek; Holger Brunck; Mike Frysinger; Stephen Warren Subject: [PATCH v3 0/9] Bring in new I2C framework It seems the timing is coming, to bring this finally in mainline and move boards over to the new i2c framework. Changes for v3 series: - Compiler collects the used i2c adapters in _u_boot_list_i2c, so no need for defining the used i2c adpaters in the board config file. - drop CONFIG_SYS_NUM_I2C_ADAPTERS and CONFIG_SYS_I2C_ADAPTERS - Some adaptions for the keymile boards, so we can drop CONFIG_I2C_MUX completely - add ppc4xx_i2c driver, ported from Dirk Eibach Serie compiles clean on arm and powerpc Ported i2c drivers: soft_i2c : from me, tested on some arm and powerpc boards fsl_i2c : from me, only compile tested tegra_i2c : ported from Simon Glass ppc4xx_i2c: adapted from Dirk Eibach dirk.eib...@gdsys.cc tested on (which board?) with 4 soft_i2c drivers and one ppc4x_i2c driver. Cc: Dirk Eibach dirk.eib...@gdsys.cc Cc: Stefan Roese s...@denx.de mailto:s...@denx.de Cc: Simon Glass s...@chromium.org mailto:s...@chromium.org Cc: Piotr Wilczek p.wilc...@samsung.com mailto:p.wilc...@samsung.com Cc: Holger Brunck holger.bru...@keymile.com mailto:holger.bru...@keymile.com Cc: Mike Frysinger vap...@gentoo.org mailto:vap...@gentoo.org Cc: Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org I ported s3c24x0_i2c driver and tested this framework on Samsung tree on Trats2 board. Please can you send a patch for this port? I posted that patch and some others with series introducing Trsts2, where I want to use this framework. I'm sorry I didn't mention it in my first mail. http://patchwork.ozlabs.org/patch/244645/ http://patchwork.ozlabs.org/patch/244644/ . http://patchwork.ozlabs.org/patch/244638/ http://patchwork.ozlabs.org/patch/244637/ http://patchwork.ozlabs.org/patch/244640/ http://patchwork.ozlabs.org/patch/244636/ Hups, missed this patches ... What is the status of this series now please? I heared nothing negatives for the new i2c multibus framework, so I plan to merge it into mainline, if the next merge widow is open. So, the best for above patches would be, If I delegate them to me, and apply them, when merging the new i2c multibus support ... In this patch set I wanted to introduce new board and use the new i2c framework at the same time. Because both go through two different tress, I finally decided to use only software i2c on the new board and switch to the new i2c framework when it is finally in the mainline. I'm sorry for confusion. @Minkyu: Is this OK for you? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Best regards, Piotr Wilczek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
