Re: [U-Boot] [PATCH 07/25] x86: Add a simple superio driver for SMSC LPC47M
Hi Simon,
On Fri, Dec 5, 2014 at 6:37 AM, Simon Glass s...@chromium.org wrote:
On 4 December 2014 at 08:01, Bin Meng bmeng...@gmail.com wrote:
On most x86 boards, the legacy serial ports (io address 0x3f8/0x2f8)
are provided by a superio chip connected to the LPC bus. We must
program the superio chip so that serial ports are available for us.
Signed-off-by: Bin Meng bmeng...@gmail.com
Acked-by: Simon Glass s...@chromium.org
But please see bits below.
---
arch/x86/include/asm/pnp_def.h | 83
++
drivers/misc/Makefile | 1 +
drivers/misc/smsc_lpc47m.c | 31
include/smsc_lpc47m.h | 19 ++
4 files changed, 134 insertions(+)
create mode 100644 arch/x86/include/asm/pnp_def.h
create mode 100644 drivers/misc/smsc_lpc47m.c
create mode 100644 include/smsc_lpc47m.h
diff --git a/arch/x86/include/asm/pnp_def.h b/arch/x86/include/asm/pnp_def.h
new file mode 100644
index 000..a16e993
--- /dev/null
+++ b/arch/x86/include/asm/pnp_def.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * Adapted from coreboot src/include/device/pnp_def.h
+ * and arch/x86/include/arch/io.h
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _ASM_PNP_DEF_H_
+#define _ASM_PNP_DEF_H_
+
+#include asm/io.h
+
+#define PNP_IDX_EN 0x30
+#define PNP_IDX_IO0 0x60
+#define PNP_IDX_IO1 0x62
+#define PNP_IDX_IO2 0x64
+#define PNP_IDX_IO3 0x66
+#define PNP_IDX_IRQ0 0x70
+#define PNP_IDX_IRQ1 0x72
+#define PNP_IDX_DRQ0 0x74
+#define PNP_IDX_DRQ1 0x75
+#define PNP_IDX_MSC0 0xf0
+#define PNP_IDX_MSC1 0xf1
+
+/* Generic functions for pnp devices */
+
+#define PNP_DEV(PORT, FUNC) (((PORT) 8) | (FUNC))
+
+static inline void pnp_write_config(uint32_t dev, uint8_t reg, uint8_t
value)
What is dev? Some sort of integer? How about a comment on PNP_DEV or here.
Sure. Will add a comment to explain dev.
+{
+ unsigned port = dev 8;
Blank line between decls and code
OK.
+ outb(reg, port);
+ outb(value, port + 1);
+}
+
+static inline uint8_t pnp_read_config(uint32_t dev, uint8_t reg)
+{
+ unsigned port = dev 8;
and here, etc.
OK.
+ outb(reg, port);
+ return inb(port + 1);
+}
+
+static inline void pnp_set_logical_device(uint32_t dev)
+{
+ unsigned device = dev 0xff;
+ pnp_write_config(dev, 0x07, device);
+}
+
+static inline void pnp_set_enable(uint32_t dev, int enable)
+{
+ pnp_write_config(dev, 0x30, enable ? 1 : 0);
+}
+
+static inline int pnp_read_enable(uint32_t dev)
+{
+ return !!pnp_read_config(dev, 0x30);
+}
+
+static inline void pnp_set_iobase(uint32_t dev, unsigned index, unsigned
iobase)
+{
+ pnp_write_config(dev, index + 0, (iobase 8) 0xff);
+ pnp_write_config(dev, index + 1, iobase 0xff);
+}
+
+static inline uint16_t pnp_read_iobase(uint32_t dev, unsigned index)
+{
+ return ((uint16_t)(pnp_read_config(dev, index)) 8) |
+ pnp_read_config(dev, index + 1);
+}
+
+static inline void pnp_set_irq(uint32_t dev, unsigned index, unsigned irq)
+{
+ pnp_write_config(dev, index, irq);
+}
+
+static inline void pnp_set_drq(uint32_t dev, unsigned index, unsigned drq)
+{
+ pnp_write_config(dev, index, drq 0xff);
+}
+
+#endif /* _ASM_PNP_DEF_H_ */
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2f2e48f..eb57497 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o
obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o
obj-$(CONFIG_NS87308) += ns87308.o
obj-$(CONFIG_PDSP188x) += pdsp188x.o
+obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
obj-$(CONFIG_STATUS_LED) += status_led.o
obj-$(CONFIG_TWL4030_LED) += twl4030_led.o
obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
diff --git a/drivers/misc/smsc_lpc47m.c b/drivers/misc/smsc_lpc47m.c
new file mode 100644
index 000..08c627d
--- /dev/null
+++ b/drivers/misc/smsc_lpc47m.c
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/pnp_def.h
+
+static void pnp_enter_conf_state(u16 dev)
+{
+ u16 port = dev 8;
here too...
OK
+ outb(0x55, port);
+}
+
+static void pnp_exit_conf_state(u16 dev)
+{
+ u16 port = dev 8;
+ outb(0xaa, port);
+}
+
+void lpc47m_enable_serial(u16 dev, u16 iobase)
+{
+ pnp_enter_conf_state(dev);
+ pnp_set_logical_device(dev);
+ pnp_set_enable(dev, 0);
+ pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+ pnp_set_enable(dev, 1);
+ pnp_exit_conf_state(dev);
+}
diff --git a/include/smsc_lpc47m.h b/include/smsc_lpc47m.h
new file mode 100644
index 000..4b11adc
--- /dev/null
+++ b/include/smsc_lpc47m.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2014, Bin Meng
Re: [U-Boot] [PATCH 10/25] x86: ich6-gpio: Add Intel Tunnel Creek GPIO support
Hi Simon,
On Fri, Dec 5, 2014 at 6:43 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:01, Bin Meng bmeng...@gmail.com wrote:
Intel Tunnel Creek GPIO register block is compatible with current
ich6-gpio driver, except the offset and content of GPIO block base
address register in the LPC PCI configuration space are different.
Use u16 instead of u32 to store the 16-bit I/O address of the GPIO
registers so that it could support both Ivybridge and Tunnel Creek.
How does that help?
The Tunnel Creek GPIO base address register bit31 is bit to control
the I/O decode of the GPIO block (1 means decode enable), while on the
Ivybridge bit31-bit16 is reserved (read returns 0).
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/include/asm/arch-queensbay/gpio.h | 13 +
arch/x86/include/asm/gpio.h| 2 +-
board/google/chromebook_link/link.c| 2 +-
drivers/gpio/intel_ich6_gpio.c | 17 -
4 files changed, 23 insertions(+), 11 deletions(-)
create mode 100644 arch/x86/include/asm/arch-queensbay/gpio.h
diff --git a/arch/x86/include/asm/arch-queensbay/gpio.h
b/arch/x86/include/asm/arch-queensbay/gpio.h
new file mode 100644
index 000..ab4e059
--- /dev/null
+++ b/arch/x86/include/asm/arch-queensbay/gpio.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _X86_ARCH_GPIO_H_
+#define _X86_ARCH_GPIO_H_
+
+/* Where in config space is the register that points to the GPIO registers?
*/
+#define PCI_CFG_GPIOBASE 0x44
+
+#endif /* _X86_ARCH_GPIO_H_ */
diff --git a/arch/x86/include/asm/gpio.h b/arch/x86/include/asm/gpio.h
index 5540d42..83878a7 100644
--- a/arch/x86/include/asm/gpio.h
+++ b/arch/x86/include/asm/gpio.h
@@ -11,7 +11,7 @@
#include asm-generic/gpio.h
struct ich6_bank_platdata {
- uint32_t base_addr;
+ uint16_t base_addr;
const char *bank_name;
};
diff --git a/board/google/chromebook_link/link.c
b/board/google/chromebook_link/link.c
index 4d95c1c..9978e92 100644
--- a/board/google/chromebook_link/link.c
+++ b/board/google/chromebook_link/link.c
@@ -125,7 +125,7 @@ int board_early_init_f(void)
return 0;
}
-void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
+void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
{
/* GPIO Set 1 */
if (gpio-set1.level)
diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index 3a2e1b0..3b2962a 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -39,12 +39,12 @@
struct ich6_bank_priv {
/* These are I/O addresses */
- uint32_t use_sel;
- uint32_t io_sel;
- uint32_t lvl;
+ uint16_t use_sel;
+ uint16_t io_sel;
+ uint16_t lvl;
};
-__weak void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
+__weak void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
{
return;
}
@@ -62,7 +62,7 @@ static int gpio_ich6_ofdata_to_platdata(struct udevice
*dev)
u8 tmpbyte;
u16 tmpword;
u32 tmplong;
- u32 gpiobase;
+ u16 gpiobase;
int offset;
/* Where should it be? */
@@ -121,11 +121,10 @@ static int gpio_ich6_ofdata_to_platdata(struct udevice
*dev)
/*
* GPIOBASE moved to its current offset with ICH6, but prior to
* that it was unused (or undocumented). Check that it looks
-* okay: not all ones or zeros, and mapped to I/O space (bit 0).
+* okay: not all ones or zeros.
*/
tmplong = pci_read_config32(pci_dev, PCI_CFG_GPIOBASE);
- if (tmplong == 0x || tmplong == 0x ||
- !(tmplong 0x0001)) {
Why take out this check?
Again the Tunnel Creek GPIO base address register bit0 is reserved
(read returns 0), while on the Ivybridge the bit0 is used to indicate
it is an I/O space.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes
-Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Thursday, December 04, 2014 7:29 PM To: Diego Santa Cruz Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes Diego Santa Cruz diego.santac...@spinetix.com wrote on 2014/11/28 12:12:56: Hi, -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Friday, November 28, 2014 11:05 AM To: Diego Santa Cruz Cc: pa...@antoniou-consulting.com; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes I have the need to hardware partition eMMC devices from U-Boot along with setting enhanced and reliable write attributes. This series of patches adds this support to U-Boot via a new mmc API, a few new members of struct mmc and a new mmc sub-command. It also features several fixes to the eMMC hardware partition support. I have tested this with Micron eMMC 4.41 parts and it is working as expected. This is really great, thanks. Good to know it may be useful to other people. I do wonder(I am fairly new to eMMC) about 512B emulation. In mmc utils there is a: mmc disable 512B emulation device Set the eMMC data sector size to 4KB by disabling emulation on device. I am hoping 4K size will increase performance and reliability? Could you add this feature too to your patch set? I think this was introduced in eMMC 4.51. I do not have any 4.51 devices at hand to test with but I am not sure there would be any performance benefit to issue reads and writes in the 4KB large sector size. All eMMC devices I've seen write in chunks much larger than 4 KB internally anyhow (the ones I'm using now have a superpage size of 32 KB). Writes should be aligned to the superpage size to get good performance. It is in eMMC 4.5 and I asked our eMMC supplier about 4KB, not only does 4KB increase performance somewhat, it also has a significant impact on device life. Write size should always be in a multiple of the superpage size to maximize performance and life, and the superpage size will be a multiple of 4 KB for any reasonable eMMC device. Currently, as far as I can tell, the mmc code does the writes in multiple blocks, by chunks of up to CONFIG_SYS_MMC_MAX_BLK_COUNT (65535 by default) 512-byte blocks, so data is written in sufficiently big chunks as long as the mmc write command is issued properly aligned and with a proper length. The eMMC device does not have to have committed the data until the end of the multiple block write command, so it should buffer up the data to sufficiently large buffers before writing them to NAND, lifting most of the performance penalty of the 512-byte sectors and, I believe, lifting all the life penalty. For a reliable write the situation may be a bit different. NAND chips nowadays use pages which are usually 8 KB and NAND pages must be written in their entirety, so even writing in chunks of 4 KB will incur a penalty if the write command is stopped every 4 KB. Furthermore, larger capacity devices use several NAND chips in parallel which makes the effective page size be the NAND chip size multiplied by the number of NAND chips, this is what the superpage size is. My guess is that 4 KB page devices may arrange the ECC differently when in native mode and may also arrange their internal block mapping metadata differently as well, leading to a performance improvement. This being said, I realized that switching to the native sector size is a one-time operation that needs to be done before hardware partitioning, so yes it would be good to add it to U-Boot. But, as I said, I do not have any 4.5 / 4.51 devices at hand to develop this feature with. While writing this I also realized that the current choice of CONFIG_SYS_MMC_MAX_BLK_COUNT being 65535 is not good, as writing more than 65535 512-byte blocks will result in issuing non-aligned writes on the second and subsequent chunks when writing 32 MiB or more in a single command. A simple fix for this would be to set the default value for CONFIG_SYS_MMC_MAX_BLK_COUNT to 65280 (i.e. aligned to 256 KiB) so that it is aligned to any reasonable superpage size. A more elaborate fix would be for b_max to be rounded down to a multiple of the superpage size read from EXT_CSD in mmc_startup(). -- Diego Santa Cruz, PhD Technology Architect spinetix.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash: do not fail even if flash_size is zero
Hi Stefan, Thanks for your quick review. I want to use this patch to clean up my board support code. ( I want to enable CONFIG_SYS_MAX_FLASH_BANKS_DETECT on my boards but in some use cases, there is a possibility that no flash is found.) CFI-flash patches are generally supposed to be applied by you, but if you do not mind, can I apply this patch with your Acked-by credit as a prerequisite for my series? On Fri, 05 Dec 2014 07:54:53 +0100 Stefan Roese s...@denx.de wrote: On 05.12.2014 04:20, Masahiro Yamada wrote: CONFIG_SYS_MAX_FLASH_BANKS_DETECT allows to determine the number of flash banks at run-time, that is, there is a possibility that no flash bank is found. It makes sense to continue the boot process without any flash device. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Stefan Roese s...@denx.de I also think its better to continue to boot in this case. So: Acked-by: Stefan Roese s...@denx.de Thanks, Stefan 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 11/25] x86: Initial import from Intel FSP release for Queensbay platform
Hi Simon, On Fri, Dec 5, 2014 at 6:49 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:01, Bin Meng bmeng...@gmail.com wrote: This is the initial import from Intel FSP release for Queensbay platform (Tunnel Creek processor and Topcliff Platform Controller Hub), which can be downloaded from Intel website. For more details, check http://www.intel.com/fsp. Note: in order to stay almost the same as the Intel release, no U-Boot coding convention will be adopted to these codes. In this commit, only convert the files from DOS format to UNIX format and trim some trailing spaces here and there. Signed-off-by: Bin Meng bmeng...@gmail.com This has mixed case and types like UINT8. Where are these resolved? All the types used by FSP (like UINT8) are resolved in fsp_types.h included in this commit. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash: do not fail even if flash_size is zero
Hi Masahiro-san, On 05.12.2014 09:40, Masahiro Yamada wrote: I want to use this patch to clean up my board support code. ( I want to enable CONFIG_SYS_MAX_FLASH_BANKS_DETECT on my boards but in some use cases, there is a possibility that no flash is found.) CFI-flash patches are generally supposed to be applied by you, but if you do not mind, can I apply this patch with your Acked-by credit as a prerequisite for my series? Sure. Please go ahead. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/25] x86: queensbay: Adapt FSP support codes
Hi Simon, On Fri, Dec 5, 2014 at 6:47 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote: Use inline assembly codes to call FspNotify() to make sure parameters are passed on the stack as required by the FSP calling convention. Also update FSP support codes license header to use SPDX ID. Acked-by: Simon Glass s...@chromium.org Does this fix all the style issues introduced in the previous patch? No, the style issues are still there. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/25] x86: Support Intel FSP initialization path in start.S
Hi Simon, On Fri, Dec 5, 2014 at 7:40 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote: Per Intel FSP architecture specification, FSP provides 3 routines for bootloader to call. The first one is the TempRamInit (aka Cache-As-Ram initialization) and the second one is the FspInit which does the memory bring up (like MRC for other x86 targets) and chipset initialization. Those two routines have to be called before U-Boot jumping to board_init_f in start.S. The FspInit() will return several memory blocks called Hand Off Blocks (HOBs) whose format is described in Platform Initialization (PI) specification (part of the UEFI specication) to the bootloader. Save this HOB address to the U-Boot global data for later use. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/start.S | 37 + arch/x86/include/asm/global_data.h | 3 +++ arch/x86/lib/asm-offsets.c | 3 +++ 3 files changed, 43 insertions(+) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index f9662fb..b4a69d2 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -75,6 +75,35 @@ early_board_init_ret: jmp car_init .globl car_init_ret car_init_ret: +#ifdef CONFIG_HAVE_FSP Can we put this code into car_init? Yes, there codes can be put into car_init. I actually considered putting them to car_init before. In the FSP case, the car_init will not return to car_init_ret. Instead it will jump directly to reserving space on stack for global data. This may look weird why car_init does not return to car_init_ret. But it is not a big problem. I will move it to car_init in v2, and put a comment in start.S to explain. + /* +* The FSP TempRamInit initializes the ecx and edx registers to +* point to a temporary but writable memory range (Cache-As-RAM). +* ecx: the start of this temporary memory range, +* edx: the end of this range. +*/ + + /* stack grows down from top of CAR */ + movl%edx, %esp + + movl$CONFIG_FSP_TEMP_RAM_ADDR, %eax + xorl%edx, %edx + xorl%ecx, %ecx + callFspInitWrapper What does this return? Can you add a a comment? Sure. + +.global fsp_init_done +fsp_init_done: + /* +* We come here from FspInit with eax pointing to the HOB list. +* Save eax to esi temporarily. +*/ + movl%eax, %esi + /* +* Re-initialize the ebp (BIST) to zero, as we already reach here +* which means we passed BIST testing before. How do you know we already reached here? In the car_init, the BIST testing will be done before any call to FSP to enable the CAR. If that fails, it will never get here. [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/25] x86: Add a simple command to show FSP HOB information
Hi Simon,
On Fri, Dec 5, 2014 at 7:42 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote:
Can we have a short commit message about what HOB is and why you want
to list it?
Sure.
[snip]
---
arch/x86/lib/Makefile | 1 +
arch/x86/lib/cmd_hob.c | 71
++
2 files changed, 72 insertions(+)
create mode 100644 arch/x86/lib/cmd_hob.c
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 55de788..73262d7 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -10,6 +10,7 @@ obj-y += bios_asm.o
obj-y += bios_interrupts.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-y += cmd_boot.o
+obj-$(CONFIG_HAVE_FSP) += cmd_hob.o
obj-y += gcc.o
obj-y += init_helpers.o
obj-y += interrupts.o
diff --git a/arch/x86/lib/cmd_hob.c b/arch/x86/lib/cmd_hob.c
new file mode 100644
index 000..bf3bd83
--- /dev/null
+++ b/arch/x86/lib/cmd_hob.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include command.h
+#include linux/compiler.h
+#include asm/arch/fsp/fsp_support.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define HOB_TYPE_MIN 0
+#define HOB_TYPE_MAX 11
ARRAY_SIZE(hob_type) ?
Yes, will fix.
+
+static char *hob_type[] = {
+ reserved,
+ Hand-off,
+ Memory Allocation,
+ Resource Descriptor,
+ GUID Extension,
+ Firmware Volumn,
+ CPU,
+ Memory Pool,
+ reserved,
+ Firmware Volumn 2,
+ Load PEIM Unused,
+ UEFI Capsule,
+};
+
+int do_hob(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ EFI_PEI_HOB_POINTERS hob;
+ UINT16 type;
+ char *desc;
+ int i = 0;
+
+ hob.Raw = (UINT8 *)gd-arch.hob_list;
+
+ printf(HOB list address: 0x%08x\n\n, (unsigned int)hob.Raw);
+
+ printf( No. | Address | Type | Length in Bytes
\n);
+
printf(-|--|--|-\n);
+ while (!END_OF_HOB_LIST(hob)) {
+ printf( %-3d | %08x |, i, (unsigned int)hob.Raw);
+ type = hob.Header-HobType;
+ if (type == EFI_HOB_TYPE_UNUSED)
+ desc = *Unused*;
+ else if (type == EFI_HOB_TYPE_END_OF_HOB_LIST)
+ desc = **END OF HOB**;
+ else if (type = HOB_TYPE_MIN type = HOB_TYPE_MAX)
+ desc = hob_type[type];
+ else
+ desc = !!!Invalid Type!!!;
+ printf( %-20s |, desc);
+ printf( %-15d \n, hob.Header-HobLength);
Can we combine those two. Also I see a space before \n - are you
running patman to check patches?
Yes, I was intending to put an additional space there. Now I don't
think it is really necessary. I was using checkscript.pl to check
patches. I will remove those spaces in v2.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/25] x86: Integrate Tunnel Creek processor microcode
Hi Simon, On Fri, Dec 5, 2014 at 7:43 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote: Integrate the processor microcode version 1.05 for Tunnel Creek, CPUID device 20661h. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/queensbay/M0220661105.inc | 1288 1 file changed, 1288 insertions(+) create mode 100644 arch/x86/cpu/queensbay/M0220661105.inc Can we put this into the device tree? Unfortunately the microcode is required by the call to TempRamInit in FSP in car_init, where the device tree functionality is not available. We can of course duplicate one in device tree for reference, not sure if it is necessary. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: fix IOMUX_PADS and SETUP_IOMUX_PAD macros definitions.
When CONFIG_MX6QDL is undefined, these definitions must be coherent with
those in mx6-pins.h. The prefix is MX6 regardless of the type of SoC.
Cc: Tim Harvey thar...@gateworks.com
Cc: Stefano Babic sba...@denx.de
Signed-off-by: Pierre Aubert p.aub...@staubli.com
---
arch/arm/include/asm/imx-common/iomux-v3.h | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h
b/arch/arm/include/asm/imx-common/iomux-v3.h
index e0a49be..a1004b5 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -199,16 +199,10 @@ if (is_cpu_type(MXC_CPU_MX6Q)) {
\
}
#define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x)/2)
-#elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
-#define IOMUX_PADS(x) MX6Q_##x
-#define SETUP_IOMUX_PAD(def) \
- imx_iomux_v3_setup_pad(MX6Q_##def);
-#define SETUP_IOMUX_PADS(x)\
- imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
#else
-#define IOMUX_PADS(x) MX6DL_##x
+#define IOMUX_PADS(x) MX6_##x
#define SETUP_IOMUX_PAD(def) \
- imx_iomux_v3_setup_pad(MX6DL_##def);
+ imx_iomux_v3_setup_pad(MX6_##def);
#define SETUP_IOMUX_PADS(x)\
imx_iomux_v3_setup_multiple_pads(x, ARRAY_SIZE(x))
#endif
--
1.7.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: complete the definition of the I2C_PADS macros
Complete the definition of the macros I2C_PADS and I2C_PADS_INFO for use
without multiple SoC type. Usefull when the same board have configurations
with or without SPL.
Cc: Stefano Babic sba...@denx.de
Cc: Nikita Kiryanov nik...@compulab.co.il
Signed-off-by: Pierre Aubert p.aub...@staubli.com
---
arch/arm/include/asm/imx-common/mxc_i2c.h | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h
b/arch/arm/include/asm/imx-common/mxc_i2c.h
index af86163..459a2e9 100644
--- a/arch/arm/include/asm/imx-common/mxc_i2c.h
+++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
@@ -50,6 +50,22 @@ struct i2c_pads_info {
#define I2C_PADS_INFO(name)\
(is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D)) ? \
mx6q_##name : mx6s_##name
+#else
+#define I2C_PADS(name, scl_i2c, scl_gpio, scl_gp, sda_i2c, sda_gpio, sda_gp) \
+ struct i2c_pads_info mx6_##name = { \
+ .scl = {\
+ .i2c_mode = MX6_##scl_i2c, \
+ .gpio_mode = MX6_##scl_gpio,\
+ .gp = scl_gp, \
+ }, \
+ .sda = {\
+ .i2c_mode = MX6_##sda_i2c, \
+ .gpio_mode = MX6_##sda_gpio,\
+ .gp = sda_gp, \
+ } \
+ }; \
+
+#define I2C_PADS_INFO(name) mx6_##name
#endif
int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
--
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 17/25] x86: Add basic support to queensbay platform and crownbay board
Hi Simon,
On Fri, Dec 5, 2014 at 7:48 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote:
Implement minimum required functions for the basic support to
queensbay platform and crownbay board.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/queensbay/Makefile | 9 +
arch/x86/cpu/queensbay/tnc.c | 48 +++
arch/x86/cpu/queensbay/tnc_car.S | 75
arch/x86/cpu/queensbay/tnc_dram.c | 81
+++
arch/x86/cpu/queensbay/tnc_pci.c | 62 ++
board/intel/crownbay/MAINTAINERS | 6 +++
board/intel/crownbay/Makefile | 7
board/intel/crownbay/crownbay.c | 20 ++
board/intel/crownbay/start.S | 9 +
9 files changed, 317 insertions(+)
create mode 100644 arch/x86/cpu/queensbay/Makefile
create mode 100644 arch/x86/cpu/queensbay/tnc.c
create mode 100644 arch/x86/cpu/queensbay/tnc_car.S
create mode 100644 arch/x86/cpu/queensbay/tnc_dram.c
create mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
create mode 100644 board/intel/crownbay/MAINTAINERS
create mode 100644 board/intel/crownbay/Makefile
create mode 100644 board/intel/crownbay/crownbay.c
create mode 100644 board/intel/crownbay/start.S
diff --git a/arch/x86/cpu/queensbay/Makefile
b/arch/x86/cpu/queensbay/Makefile
new file mode 100644
index 000..ace04ca
--- /dev/null
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += tnc_car.o tnc_dram.o tnc.o
+obj-y += fsp_configs.o fsp_support.o
+obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
new file mode 100644
index 000..c0d19aa
--- /dev/null
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/post.h
+#include asm/arch/fsp/fsp_support.h
+
+int arch_cpu_init(void)
+{
+ post_code(POST_CPU_INIT);
+#ifdef CONFIG_SYS_X86_TSC_TIMER
+ timer_set_base(rdtsc());
+#endif
+
+ return x86_cpu_init_f();
+}
+
+int print_cpuinfo(void)
+{
+ post_code(POST_CPU_INFO);
+ return default_print_cpuinfo();
+}
+
+void reset_cpu(ulong addr)
+{
+ /* cold reset */
+ outb(0x06, 0xcf9);
I think there is a constant somewhere for cf9?
Yes, I found one in arch/x86/include/asm/processor.h and will use that.
+}
+
+void board_final_cleanup(void)
+{
+ EFI_STATUS status;
+
+ /* call into FspNotify */
Remove blank line
OK.
+
+ debug(Calling into FSP (notify phase EnumInitPhaseReadyToBoot): );
+ status = FspNotifyWrapper(NULL, EnumInitPhaseReadyToBoot);
Are we stuck with these mixed case identifiers?
I may have to fix FSP support library coding style issues in v2.
+ if (status != FSP_SUCCESS)
+ debug(fail, error code %x\n, status);
+ else
+ debug(OK\n);
+
+ return;
+}
diff --git a/arch/x86/cpu/queensbay/tnc_car.S
b/arch/x86/cpu/queensbay/tnc_car.S
new file mode 100644
index 000..722de7f
--- /dev/null
+++ b/arch/x86/cpu/queensbay/tnc_car.S
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include asm/post.h
+
+.globl car_init
+car_init:
+ /*
+* Note: ebp holds the BIST value (built-in self test) so far, but
ebp
+* will be destroyed through the FSP call, thus we have to test the
+* BIST value here before we call into FSP.
+*/
+ test%ebp, %ebp
+ jz car_init_start
+ post_code(POST_BIST_FAILURE)
+ jmp die
Is there no way to save it anywhere?
Unfortunately I did not find a way to save the ebp through the FSP
call so far. The FSP documentation mentions that FSP tries to save
bootloader's stack before call to FspInit to a temporary memory block
after the call, however I found it is not working as documented. I may
look into this in the future, but for now I think we have to let it
be.
+
+car_init_start:
+ post_code(POST_CAR_START)
+ lea find_fsp_header_stack, %esp
+ jmp FindFspHeader
+
+find_fsp_header_ret:
+ /* EAX points to FSP_INFO_HEADER */
+ mov %eax, %ebp
+
+ /* sanity test */
+ cmp $CONFIG_FSP_LOCATION, %eax
+ jb die
+
+ /* calculate TempRamInitEntry address */
+ mov 0x30(%ebp), %eax
+ add 0x1c(%ebp), %eax
+
+ /* call FSP TempRamInitEntry to setup temporary stack */
+ lea temp_ram_init_stack, %esp
+ jmp *%eax
+
+temp_ram_init_ret:
+
Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes
Diego Santa Cruz diego.santac...@spinetix.com wrote on 2014/12/05 09:38:34: -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Thursday, December 04, 2014 7:29 PM To: Diego Santa Cruz Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes Diego Santa Cruz diego.santac...@spinetix.com wrote on 2014/11/28 12:12:56: Hi, -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Friday, November 28, 2014 11:05 AM To: Diego Santa Cruz Cc: pa...@antoniou-consulting.com; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes I have the need to hardware partition eMMC devices from U-Boot along with setting enhanced and reliable write attributes. This series of patches adds this support to U-Boot via a new mmc API, a few new members of struct mmc and a new mmc sub-command. It also features several fixes to the eMMC hardware partition support. I have tested this with Micron eMMC 4.41 parts and it is working as expected. This is really great, thanks. Good to know it may be useful to other people. I do wonder(I am fairly new to eMMC) about 512B emulation. In mmc utils there is a: mmc disable 512B emulation device Set the eMMC data sector size to 4KB by disabling emulation on device. I am hoping 4K size will increase performance and reliability? Could you add this feature too to your patch set? I think this was introduced in eMMC 4.51. I do not have any 4.51 devices at hand to test with but I am not sure there would be any performance benefit to issue reads and writes in the 4KB large sector size. All eMMC devices I've seen write in chunks much larger than 4 KB internally anyhow (the ones I'm using now have a superpage size of 32 KB). Writes should be aligned to the superpage size to get good performance. It is in eMMC 4.5 and I asked our eMMC supplier about 4KB, not only does 4KB increase performance somewhat, it also has a significant impact on device life. Write size should always be in a multiple of the superpage size to maximize performance and life, and the superpage size will be a multiple of 4 KB for any reasonable eMMC device. Currently, as far as I can tell, the mmc code does the writes in multiple blocks, by chunks of up to CONFIG_SYS_MMC_MAX_BLK_COUNT (65535 by default) 512-byte blocks, so data is written in sufficiently big chunks as long as the mmc write command is issued properly aligned and with a proper length. The eMMC device does not have to have committed the data until the end of the multiple block write command, so it should buffer up the data to sufficiently large buffers before writing them to NAND, lifting most of the performance penalty of the 512-byte sectors and, I believe, lifting all the life penalty. For a reliable write the situation may be a bit different. Yes, reliable write is the key(which we need, doesn't everybody? :). This is even default for some eMMC devices. This being said, I realized that switching to the native sector size is a one-time operation that needs to be done before hardware partitioning, so yes it would be good to add it to U-Boot. But, as I said, I do not have any 4.5 / 4.51 devices at hand to develop this feature with. You could just copy the code from mmc-utils and do a RFC impl. with a big fat warning attached to it. While writing this I also realized that the current choice of CONFIG_SYS_MMC_MAX_BLK_COUNT being 65535 is not good, as writing more than 65535 512-byte blocks will result in issuing non-aligned writes on the second and subsequent chunks when writing 32 MiB or more in a single command. A simple fix for this would be to set the default value for CONFIG_SYS_MMC_MAX_BLK_COUNT to 65280 (i.e. aligned to 256 KiB) so that it is aligned to any reasonable superpage size. A more elaborate fix would be for b_max to be rounded down to a multiple of the superpage size read from EXT_CSD in mmc_startup(). yes, you could consider 4 MiB alignment as well, http://lwn.net/Articles/428584/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes
-Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Friday, December 05, 2014 10:46 AM To: Diego Santa Cruz Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes [snip] Write size should always be in a multiple of the superpage size to maximize performance and life, and the superpage size will be a multiple of 4 KB for any reasonable eMMC device. Currently, as far as I can tell, the mmc code does the writes in multiple blocks, by chunks of up to CONFIG_SYS_MMC_MAX_BLK_COUNT (65535 by default) 512-byte blocks, so data is written in sufficiently big chunks as long as the mmc write command is issued properly aligned and with a proper length. The eMMC device does not have to have committed the data until the end of the multiple block write command, so it should buffer up the data to sufficiently large buffers before writing them to NAND, lifting most of the performance penalty of the 512-byte sectors and, I believe, lifting all the life penalty. For a reliable write the situation may be a bit different. Yes, reliable write is the key(which we need, doesn't everybody? :). This is even default for some eMMC devices. This being said, I realized that switching to the native sector size is a one-time operation that needs to be done before hardware partitioning, so yes it would be good to add it to U-Boot. But, as I said, I do not have any 4.5 / 4.51 devices at hand to develop this feature with. You could just copy the code from mmc-utils and do a RFC impl. with a big fat warning attached to it. Then I leave it as an exercise for the reader :-) Note that after setting a 4 KB device to its native sector size you cannot issue any read nor write whose offset or size is not 4KB aligned, I do not know if all U-Boot code is currently capable of this, otherwise the mmc read / write code needs to emulate unaligned accesses. While writing this I also realized that the current choice of CONFIG_SYS_MMC_MAX_BLK_COUNT being 65535 is not good, as writing more than 65535 512-byte blocks will result in issuing non-aligned writes on the second and subsequent chunks when writing 32 MiB or more in a single command. A simple fix for this would be to set the default value for CONFIG_SYS_MMC_MAX_BLK_COUNT to 65280 (i.e. aligned to 256 KiB) so that it is aligned to any reasonable superpage size. A more elaborate fix would be for b_max to be rounded down to a multiple of the superpage size read from EXT_CSD in mmc_startup(). yes, you could consider 4 MiB alignment as well, http://lwn.net/Articles/428584/ It seems to me that 4 MiB alignment for breaking up a large write into chunks is overkill. It is the user of the eMMC that should take care to align things to 4 MiB or similar. I guess it would be even better to align the things to the write protect group or erase size. I'll cook something up for this issue as soon as I have some spare time. Best, -- Diego Santa Cruz, PhD Technology Architect spinetix.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/10] dm: Add I2C support and convert sandbox, tegra
Hello, On 12/04/2014 03:00 AM, Simon Glass wrote: Hi Przemyslaw, On 3 December 2014 at 09:13, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello all, On 11/24/2014 07:57 PM, Simon Glass wrote: This series adds I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly it is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree, assuming that we want to support this. The following I2C CONFIGs are no-longer needed when driver model is used: CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method CONFIG_I2C_MULTI_BUS - we always support multi-bus with driver model CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses CONFIG_SYS_I2C_SPEED - the device tree specifies the speed for each bus CONFIG_SYS_I2C- this is the 'new old' API, now deprecated There are a few SPI patches included here due to a dependency on a new device binding function. v3 changes the uclass to driver interface significantly. It is now a list of messages to be processed by the driver. This matches the Linux user space API which may be a benefit. It does introduce one complication, which is that the protocol does not support separate chip offset and data. I have enhanced it to do so. This series is available at u-boot-dm/i2c-working2. Changes in v3: - Change uclass = driver API to use a message list - Correct bogus address len code (was confused with chip address length) - Drop extra call to i2c_bind_driver() in i2c_probe() - Add a helper to query chip flags - Add support for reading a byte at a time with an address for each byte - Adjust for slightly altered I2C uclass API - Add new 'i2c flags' command to get/set chip flags - Update for new uclass = driver interface - Update emulator for new uclass interface - Update for new uclass = emulateor interface - Change driver to support new message-based I2C uclass API Changes in v2: - Fix cihp typo - Implement generic I2C devices to allow 'i2c probe' on unknown devices - Return the probed device from i2c_probe() - Set the bus speed after the bus is probed - Add some debugging for generic I2C device binding - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction - Add a helper function to find a chip on a particular bus number - Change alen to int so that it can be -1 (this was a bug) - Call the deblock() method for 'i2c reset' - Update commit message for EEPROM driver - Add a test for automatic binding of generic I2C devices - Add a new asm/test.h header for tests in sandbox - Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices - Correct the compatible strings for I2C buses - Don't init if the speed is 0, since this breaks the controller - Expand coverage to all Tegra boards Simon Glass (10): dm: i2c: Add a uclass for I2C dm: i2c: Implement driver model support in the i2c command dm: i2c: Add I2C emulation driver for sandbox dm: i2c: Add a sandbox I2C driver dm: i2c: Add an I2C EEPROM simulator dm: i2c: config: Enable I2C for sandbox using driver model dm: i2c: dts: Add an I2C bus for sandbox dm: Add a simple EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/dts/tegra124-jetson-tk1.dts| 1 - arch/arm/dts/tegra124-norrin.dts| 1 -
Re: [U-Boot] [PATCH v4 01/11] dm: i2c: Add a uclass for I2C
Hi Simon,
Here are some comments on v4.
On Thu, 4 Dec 2014 21:21:20 -0700
Simon Glass s...@chromium.org wrote:
+#define I2C_MAX_OFFSET_LEN 4
+
+/**
+ * i2c_setup_offset() - Set up a new message with a chip offset
+ *
+ * @chip:Chip to use
+ * @offset: Byte offset within chip
+ * @offset_buf: Place to put byte offset
+ * @msg: Message buffer
+ * @return 0 if OK, -EADDRNOTAVAIL if the offset length is 0. In that case
the
+ * message is still set up but will not contain an offset.
+ */
+static int i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
+ uint8_t offset_buf[], struct i2c_msg *msg)
+{
+ int offset_len;
+
+ msg-addr = chip-chip_addr;
+ msg-flags = chip-flags DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
+ msg-len = chip-offset_len;
+ msg-buf = offset_buf;
+ if (!chip-offset_len)
+ return -EADDRNOTAVAIL;
I notice i2c_{read|write}_bytewise checks the return code of this
function, but the normal one does not.
I think it seems a little bit strange.
Instead of the code above, can we put this here?
if (chip-offset_len I2C_MAX_OFFSET_LEN)
return -EADDRNOTAVAIL;
And then, the normal i2c_{read|write} should also check the return code of this.
if (!chip-offset_len)
return -EADDRNOTAVAIL;
is specific to *_bytewise ones, so it can be moved to there.
+ offset_len = chip-offset_len;
+ while (offset_len--)
+ *offset_buf++ = offset (8 * offset_len);
We should be very careful about this code
because buffer overrun happens if too big offset_len is given.
So, we should make sure that offset_len is no larger than I2C_MAX_OFFSET_LEN.
(Or, you can pass the length of offset_buf[] to this function.)
I know you implemented a similar check check in i2c_set_chip_offset_len()
function.
But users can skip i2c_set_chip_offset_len() and
directly invoke i2c_read() or i2c_write().
This is very dangerous.
+int i2c_write(struct udevice *dev, uint offset, const uint8_t *buffer, int
len)
+{
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ struct udevice *bus = dev_get_parent(dev);
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[1];
+
+ if (!ops-xfer)
+ return -ENOSYS;
+
+ if (chip-flags DM_I2C_CHIP_RE_ADDRESS)
+ return i2c_write_bytewise(dev, offset, buffer, len);
Have you noticed that do_i2c_write() function in common/cmd_i2c.c
always does the bytewise-equivalent behavior?
(It uses a while() loop and in each loop it calls i2c_write with length=1)
On the other hand, do_i2c_read() does not split it into small chunks.
At first I was wondering why only do_i2c_write() must split into many
small transactions, but I got an answer when I was testing it on my board.
My on-board EEPROM chip does not work with long-burst write,
but it works with any long-burst read.
It turned out some chips (at least mine) require DM_I2C_CHIP_RE_ADDRESS
only for write.
Maybe, do we need to have a _RE_ADDRESS flag for each of write/read?
+static int i2c_probe_chip(struct udevice *bus, uint chip_addr,
+ enum dm_i2c_chip_flags flags)
I notice you added flags argument in v4.
When and how do we use this flag ?
for DM_I2C_CHIP_10BIT ??
+{
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[1];
+ uint8_t ch = 0;
+ int ret;
+
+ if (ops-probe_chip) {
+ ret = ops-probe_chip(bus, chip_addr, flags);
+ if (!ret || ret != -ENOSYS)
+ return ret;
+ }
+
+ if (!ops-xfer)
+ return -ENOSYS;
+
+ /* Probe with a zero-length message */
+ msg-addr = chip_addr;
+ msg-flags = 0;
If my guess is correct, this line should be like this?
ptr-flags = chip-flags DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
I am not sure..
+
+/*
+ * i2c_get_bus_speed:
+ *
+ * Returns speed of selected I2C bus in Hz
+ */
+int i2c_get_bus_speed(struct udevice *bus)
+{
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct dm_i2c_bus *i2c = bus-uclass_priv;
+
+ if (!ops-set_bus_speed)
+ return i2c-speed_hz;
+
+ return ops-get_bus_speed(bus);
+}
If ops-set_bus_speed is missing, ops-get_bus_speed is never called even if
it exists.
Isn't it a bit strange?
It is not clear to me why set_bus_speed must be checked.
Why isn't it like this?
int i2c_get_bus_speed(struct udevice *bus)
{
struct dm_i2c_ops *ops = i2c_get_ops(bus);
struct dm_i2c_bus *i2c = bus-uclass_priv;
if (ops-get_bus_speed(bus)
return ops-get_bus_speed(bus);
return i2c-speed_hz;
}
When opt-set_bus_speed is missing, I think there are two possibilities:
[1] Changing the bus speed is not supported
[2] Hardware registers are set in .xfer handler
In case [2], somebody still might want to read
Re: [U-Boot] [PATCH v4 11/11] dm: i2c: tegra: Convert to driver model
Hi Simon,
On Thu, 4 Dec 2014 21:21:30 -0700
Simon Glass s...@chromium.org wrote:
+static const struct dm_i2c_ops tegra_i2c_ops = {
+ .xfer = tegra_i2c_xfer,
+ .probe_chip = tegra_i2c_probe_chip,
+ .set_bus_speed = tegra_i2c_set_bus_speed,
+};
- for (i = 0; i TEGRA_I2C_NUM_CONTROLLERS; i++) {
- struct i2c_bus *bus = i2c_controllers[i];
+static int tegra_i2c_child_pre_probe(struct udevice *dev)
+{
+ struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
- if (bus-inited bus-is_dvc)
- return i;
- }
+ if (dev-of_offset == -1)
+ return 0;
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
+i2c_chip);
+}
As I said in v3, it is unfortunate that uclass does not support
.child_pre_probe.
sandbox_i2c.c and tegra-i2c.c have a similar .child_pre_probe.
I copied tegra_i2c_child_pre_probe() to my i2c driver verbatim.
I guess every driver will do so.
Is it a good idea to move .child_pre_probe to uclass_driver?
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 18/25] x86: Add queensbay and crownbay Kconfig files
Hi Simon, On Fri, Dec 5, 2014 at 7:54 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:03, Bin Meng bmeng...@gmail.com wrote: Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/Kconfig | 13 arch/x86/cpu/queensbay/Kconfig | 75 ++ board/intel/crownbay/Kconfig | 20 +++ 3 files changed, 108 insertions(+) create mode 100644 arch/x86/cpu/queensbay/Kconfig create mode 100644 board/intel/crownbay/Kconfig diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fdfb618..ebf72b3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -32,6 +32,15 @@ config TARGET_CHROMEBOOK_LINK and it provides a 2560x1700 high resolution touch-enabled LCD display. +config TARGET_CROWNBAY + bool Support Intel Crown Bay CRB + help + This is the Intel Crown Bay Customer Reference Board. It contains + the Intel Atom Processor E6xx populated on the COM Express module + with 1GB DDR2 soldered down memory and a carrier board with the + Intel Platform Controller Hub EG20T, other system components and + peripheral connectors for PCIe/SATA/USB/LAN/SD/UART/Audio/LVDS. + endchoice config RAMBASE @@ -310,8 +319,12 @@ endmenu source arch/x86/cpu/ivybridge/Kconfig +source arch/x86/cpu/queensbay/Kconfig + source board/coreboot/coreboot/Kconfig source board/google/chromebook_link/Kconfig +source board/intel/crownbay/Kconfig + endmenu diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig new file mode 100644 index 000..3441413 --- /dev/null +++ b/arch/x86/cpu/queensbay/Kconfig @@ -0,0 +1,75 @@ +# +# Copyright (C) 2014, Bin Meng bmeng...@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +config INTEL_QUEENSBAY + bool + select HAVE_FSP + select HAVE_CMC + +if INTEL_QUEENSBAY + +config HAVE_FSP + bool Add an Firmware Support Package binary + help + Select this option to add an Firmware Support Package binary to + the resulting U-Boot image. It is a binary blob which U-Boot uses + to set up SDRAM and other chipset specific initialization. + + Note: Without this binary U-Boot will not be able to set up its + SDRAM so will not boot. + +config FSP_FILE + string Firmware Support Package binary path and filename + depends on HAVE_FSP + default fsp.bin + help + The path and filename of the file to use as Firmware Support Package + binary. + +config FSP_LOCATION + hex Firmware Support Package binary location + depends on HAVE_FSP + default 0xfffc + help + FSP is not Pisition Independent Code (PIC) and the whole FSP has to Position OK. + be rebased if it is placed at a location which is different from the + perferred base address specified during the FSP build. Use Intel's + Binary Configuration Tool (BCT) to do the rebase. + + The default base address of 0xfffc indicates that the binary must + be located at offset 0xc from the beginning of a 1MB flash device. + +config FSP_TEMP_RAM_ADDR + hex + default 0x200 help? OK. + +config HAVE_CMC + bool Add a Chipset Micro Code state machine binary + help + Select this option to add a Chipset Micro Code state machine binary + to the resulting U-Boot image. It is a binary blob which must be put + in the flash for the processor to access when power up. powered up Can you add help about what it does? The datasheet does not mention too much details about CMC, but I will try adding more help about it. + +config CMC_FILE + string Chipset Micro Code state machine binary path and filename + depends on HAVE_CMC + default C0_22211.BIN Can we use lower case please? Yes. [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/25] x86: Add crownbay defconfig and config.h
Hi Simon,
On Fri, Dec 5, 2014 at 7:56 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:03, Bin Meng bmeng...@gmail.com wrote:
Signed-off-by: Bin Meng bmeng...@gmail.com
---
configs/crownbay_defconfig | 6 ++
include/configs/crownbay.h | 52
++
2 files changed, 58 insertions(+)
create mode 100644 configs/crownbay_defconfig
create mode 100644 include/configs/crownbay.h
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
new file mode 100644
index 000..ce90553
--- /dev/null
+++ b/configs/crownbay_defconfig
@@ -0,0 +1,6 @@
+CONFIG_SYS_EXTRA_OPTIONS=SYS_TEXT_BASE=0xfff0
+CONFIG_X86=y
+CONFIG_TARGET_CROWNBAY=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_SEPARATE=y
+CONFIG_DEFAULT_DEVICE_TREE=crownbay
diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
new file mode 100644
index 000..2314e62
--- /dev/null
+++ b/include/configs/crownbay.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * board/config.h - configuration options, board specific
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include configs/x86-common.h
+
+#define CONFIG_SYS_MONITOR_LEN (1 20)
+#define CONFIG_SYS_X86_START16 0xf800
+#define CONFIG_BOARD_EARLY_INIT_F
+
+#define CONFIG_X86_RESET_VECTOR
+#define CONFIG_NR_DRAM_BANKS 1
+
+#define CONFIG_COREBOOT_SERIAL
Do you think you could create a patch to rename this to x86_serial?
Sure, I can.
+#define CONFIG_SMSC_LPC47M
+
+#define CONFIG_PCI_MEM_BUS 0x4000
+#define CONFIG_PCI_MEM_PHYSCONFIG_PCI_MEM_BUS
+#define CONFIG_PCI_MEM_SIZE0x8000
+
+#define CONFIG_PCI_PREF_BUS0xc000
+#define CONFIG_PCI_PREF_PHYS CONFIG_PCI_PREF_BUS
+#define CONFIG_PCI_PREF_SIZE 0x2000
+
+#define CONFIG_PCI_IO_BUS 0x2000
+#define CONFIG_PCI_IO_PHYS CONFIG_PCI_IO_BUS
+#define CONFIG_PCI_IO_SIZE 0xe000
+
+#define CONFIG_SYS_EARLY_PCI_INIT
+#define CONFIG_PCI_PNP
+
+#define CONFIG_STD_DEVICES_SETTINGS stdin=serial\0 \
+ stdout=serial\0 \
+ stderr=serial\0
+
+#define CONFIG_SCSI_DEV_LIST\
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SATA}
+
+/* Video is not supported */
+#undef CONFIG_VIDEO
+#undef CONFIG_CFB_CONSOLE
Why is video not supported?
Tunnel Creek has one GPU integrated, but on my Crown Bay board, the
output siginal is routed to LVDS to be connected to an external LCD,
which I don't have for now. There is no public datasheet describing
the details about the integrated GPU, neither did I found a legacy
video ROM supporting that. There seems to be a UEFI native graphics
driver from Intel, but that means I will need study that and write a
U-Boot native graphics driver, which needs some time. Maybe supporting
PCIe based graphics card is an option, and I will find some time to
try that.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] x86: Include FSP and CMC binary in the u-boot.rom build rules
Hi Simon, On Fri, Dec 5, 2014 at 7:57 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:03, Bin Meng bmeng...@gmail.com wrote: Signed-off-by: Bin Meng bmeng...@gmail.com --- Makefile | 8 1 file changed, 8 insertions(+) diff --git a/Makefile b/Makefile index c9ae77b..abfb74b 100644 --- a/Makefile +++ b/Makefile @@ -976,6 +976,14 @@ ifneq ($(CONFIG_HAVE_MRC),) IFDTOOL_FLAGS += -w $(CONFIG_X86_MRC_START):$(srctree)/board/$(BOARDDIR)/mrc.bin endif +ifneq ($(CONFIG_HAVE_FSP),) +IFDTOOL_FLAGS += -w $(CONFIG_FSP_LOCATION):$(CONFIG_FSP_FILE) Can we stay consistent - e.g. START instead of LOCATION? or ADDR? Granted it's not 100% consistent now. Sure. I believe we can use ADDR for all these blobs. +endif + +ifneq ($(CONFIG_HAVE_CMC),) +IFDTOOL_FLAGS += -w $(CONFIG_CMC_LOCATION):$(CONFIG_CMC_FILE) +endif + ifneq ($(CONFIG_X86_OPTION_ROM_ADDR),) IFDTOOL_FLAGS += -w $(CONFIG_X86_OPTION_ROM_ADDR):$(srctree)/board/$(BOARDDIR)/$(CONFIG_X86_OPTION_ROM_FILENAME) endif -- 1.8.2.1 Regards, Simon Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/25] x86: crownbay: Add SPI flash support
Hi Simon,
On Fri, Dec 5, 2014 at 7:59 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:03, Bin Meng bmeng...@gmail.com wrote:
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/queensbay/tnc.c | 26 +-
include/configs/crownbay.h | 2 ++
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index c0d19aa..eea70c0 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -6,17 +6,41 @@
#include common.h
#include asm/io.h
+#include asm/pci.h
#include asm/post.h
#include asm/arch/fsp/fsp_support.h
+/* PCI Configuration Space (D31:F0): LPC */
+#define PCH_LPC_DEVPCI_BDF(0, 0x1f, 0)
Can this go in a header file somwhere?
Sure.
+
+static void unprotect_spi_flash(void)
+{
+ u32 bc;
+
+ bc = pci_read_config32(PCH_LPC_DEV, 0xd8);
+ bc |= 0x1; /* unprotect the flash */
+ pci_write_config32(PCH_LPC_DEV, 0xd8, bc);
+}
+
int arch_cpu_init(void)
{
+ struct pci_controller *hose;
+ int ret;
+
post_code(POST_CPU_INIT);
#ifdef CONFIG_SYS_X86_TSC_TIMER
timer_set_base(rdtsc());
#endif
- return x86_cpu_init_f();
+ x86_cpu_init_f();
Need to check error return.
Looks like x86_cpu_init_f() always returns 0, but it is no harm to do
the check return. I will do it in v2.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/25] x86: crownbay: Add SDHCI support
Hi Simon,
On Fri, Dec 5, 2014 at 8:01 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:04, Bin Meng bmeng...@gmail.com wrote:
There are two standard SD card slots on the Crown Bay board, which
are connected to the Topcliff PCH SDIO controllers. Enable the SDHC
support so that we can use them.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/queensbay/Makefile | 2 +-
arch/x86/cpu/queensbay/topcliff.c | 44
+++
include/configs/crownbay.h| 6 ++
3 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/cpu/queensbay/topcliff.c
diff --git a/arch/x86/cpu/queensbay/Makefile
b/arch/x86/cpu/queensbay/Makefile
index ace04ca..2c2ec01 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -4,6 +4,6 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-y += tnc_car.o tnc_dram.o tnc.o
+obj-y += tnc_car.o tnc_dram.o tnc.o topcliff.o
obj-y += fsp_configs.o fsp_support.o
obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/cpu/queensbay/topcliff.c
b/arch/x86/cpu/queensbay/topcliff.c
new file mode 100644
index 000..4d2a24a
--- /dev/null
+++ b/arch/x86/cpu/queensbay/topcliff.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include errno.h
+#include malloc.h
+#include pci.h
+#include pci_ids.h
+#include sdhci.h
+
+static struct pci_device_id mmc_supported[] = {
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0 },
+ { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1 },
+ { }
+};
+
+int cpu_mmc_init(bd_t *bis)
+{
+ struct sdhci_host *mmc_host;
+ pci_dev_t devbusfn;
+ u32 iobase;
+ int i;
+
+ for (i = 0; i 2; i++) {
What is 2? Is it ARRAY_SIZE(mmc_supported)?
Yes, will change it to that.
+ devbusfn = pci_find_devices(mmc_supported, i);
+ if (devbusfn == -1)
+ return -ENODEV;
+
+ mmc_host = (struct sdhci_host *)malloc(sizeof(struct
sdhci_host));
+ if (!mmc_host)
+ return -ENOMEM;
+
+ mmc_host-name = Topcliff SDHCI;
+ pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, iobase);
+ mmc_host-ioaddr = (void *)iobase;
+ mmc_host-quirks = 0;
+ add_sdhci(mmc_host, 0, 0);
Please check error retrun.
OK.
[snip]
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 25/25] x86: Add a README.x86 for U-Boot on x86 support
Hi Simon, On Fri, Dec 5, 2014 at 8:03 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:04, Bin Meng bmeng...@gmail.com wrote: Signed-off-by: Bin Meng bmeng...@gmail.com --- doc/README.x86 | 123 + 1 file changed, 123 insertions(+) create mode 100644 doc/README.x86 diff --git a/doc/README.x86 b/doc/README.x86 new file mode 100644 index 000..a79f510 --- /dev/null +++ b/doc/README.x86 @@ -0,0 +1,123 @@ +# +# Copyright (C) 2014, Simon Glass s...@chromium.org +# Copyright (C) 2014, Bin Meng bmeng...@gmail.com +# +# SPDX-License-Identifier: GPL-2.0+ +# + +U-Boot on x86 += Very nice! + +This document describes the information about U-Boot running on x86 targets, +including supported boards, build instructions, todo list, etc. + +Status +-- +U-Boot supports running as a coreboot [1] payload on x86. So far only link +(Chromebook pixel) has been tested, but it should work with minimal adjustments +on other x86 boards since coreboot deals with most of the low-level details. + +U-Boot also supports booting directly from x86 reset vector without coreboot, +aka raw support or bare support. Currently Google Chromebook link and Intel +Crown Bay board support running U-Boot 'bare metal'. + +As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux +kernel as part of a FIT image. It also supports a compressed zImage. + +Build Instructions +-- +Building U-Boot as a coreboot payload is just like building U-Boot for targets +on other architectures, like below: + +$ make coreboot-x86_defconfig +$ make all + +Building rom version U-Boot (hereafter referred to as u-boot.rom) is a little +bit tricky, as generally it requires several binary blobs which are not shipped +in the U-Boot source tree. Due to this reason, the u-boot.rom build is not +turned on by default in the U-Boot source tree. Firstly, you need turn it on +by uncommenting the following line in the main U-Boot Makefile: + +# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom + +Google Chromebook link specific instructions: + +Firstly, you need the following binary blobs: + +* descriptor.bin - Intel flash descriptor +* me.bin - Intel Management Engine +* mrc.bin - Memory Reference Code, which sets up SDRAM +* video ROM - sets up the display + +You can get these binary blobs by: + +$ git clone http://review.coreboot.org/p/blobs.git +$ cd blobs + +Find the following files: + +* ./mainboard/google/link/descriptor.bin +* ./mainboard/google/link/me.bin +* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin + +The 3rd one should be renamed to mrc.bin. +As for the video ROM, you can get it here [2]. + +Now you can build U-Boot and obtain u-boot.rom: + +$ make chromebook_link_defconfig +$ make all + +Intel Crown Bay specific instructions: + +U-Boot support of Intel Crown Bay board [3] relies on a binary blob called +Firmware Support Package [4] to perform all the necessary initialization steps +as documented in the BIOS Writer Guide including initialization of the CPU, +memory controller, chipset and certain bus interfaces. + +Downalod the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T, +install it on your host and locate the FSP binary blob. Note this platform +also requires a Chipset Micro Code (CMC) state machine binary to be present in +the SPI flash where u-boot.rom resides, and this CMC binary blob can be found +in this FSP package too. Can we just put them in the board directory with standard names? Yes, will do it in v2. + +* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd +* ./Microcode/C0_22211.BIN + +Now you can build U-Boot and obtaim u-boot.rom + +$ make crownbay_defconfig +$ make menuconfig # points FSP and CMC binary path to the correct one Best if we can avoid that step. I will update the instructions to use the standard binary blob names, so that this step can be omitted. +$ make all + +CPU Microcode +- +Modern CPU usually requires a special bit stream called microcode [5] to be +loaded on the processor after power up in order to function properly. U-Boot +has already integrated these as hex dumps in the source tree. + +Driver Model + +x86 has been converted to use driver model for serial and GPIO. + +Device Tree +--- +x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to +be turned on. Not every device on the board is configured via devie tree, but +more and more devices will be added as time goes by. Check out the directory +arch/x86/dts/ for these device tree source files. + +TODO List +- +- MTRR support (for performance) I'm interested - does the lack of this make your board slow? I believe the FSP binary blob already has the MTRR support, and U-Boot running on my board
Re: [U-Boot] [PATCH 00/25] x86: Add Intel Queensbay platform support
Hi Simon, On Fri, Dec 5, 2014 at 8:04 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:00, Bin Meng bmeng...@gmail.com wrote: This patch series add the Intel Queensbay platform support. The Queensbay platform includes an Atom E6xx processor (codename Tunnel Creek) and a Platform Controller Hub EG20T (codename Topcliff). The support depends on Intel Firmware Support Package (FSP) to initialize the processor and chipset including system memory. With this patch series, U-Boot boots to Linux kernel. Validated on an Intel Crown Bay board with kernel 3.17. Note I did not clean up the original FSP codes released by Intel with U-Boot coding convention. So there will be coding style issues reported by the patch checkers against patch#11 and #12 in this series. I've acked some of this - let me know if you would like me to apply things out of order, etc. Otherwise I'll wait. Thanks for acking/reviewing them so quickly! Let me rework and send the v2 patch series so that you can apply them one-time. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Using u-boot with qemu-system-mips(qemu-2.1.2) caused infinite loop
Hi, On 04.12.2014 08:55, jiang wrote: Hello all: I just downloaded the latest u-boot source code,then compiled with: make qemu_mips_defconfig make CROSS_COMPILE=mips-linux-uclibc- then create image: # dd of=flash bs=1k count=4k if=/dev/zero # dd of=flash bs=1k conv=notrunc if=u-boot.bin run with: qemu-system-mips -M mips -pflash flash -nographic but I got nothing then I try to debug with gdb,I got this: 0xbfc001fc _start+508:nop 0xbfc00200 _start+512:b0xbfc00200 _start+512 0xbfc00204 _start+516:nop 0xbfc00208 _start+520:nop with recent Qemu versions there occurs a CPU exception in CFI probing Another thing, the file u-boot.bin I got was 215k, is that ok? What should I do to use u-boot in qemu?:) if you don't need 64bit support, you should use the malta board for Qemu $ make malta_defconfig $ make CROSS_COMPILE=mips-linux-uclibc- $ qemu-system-mips -M malta -m 256 -nographic -bios u-boot.bin U-Boot 2015.01-rc2-00163-g97cdf64 (Dec 05 2014 - 15:06:30) Board: MIPS Malta CoreLV DRAM: 256 MiB Flash: 4 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Net: pcnet#0 Warning: pcnet#0 using MAC address from net device malta # -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/25] x86: Add Intel Queensbay platform support
Hi Bin, On 5 December 2014 at 07:07, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Dec 5, 2014 at 8:04 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:00, Bin Meng bmeng...@gmail.com wrote: This patch series add the Intel Queensbay platform support. The Queensbay platform includes an Atom E6xx processor (codename Tunnel Creek) and a Platform Controller Hub EG20T (codename Topcliff). The support depends on Intel Firmware Support Package (FSP) to initialize the processor and chipset including system memory. With this patch series, U-Boot boots to Linux kernel. Validated on an Intel Crown Bay board with kernel 3.17. Note I did not clean up the original FSP codes released by Intel with U-Boot coding convention. So there will be coding style issues reported by the patch checkers against patch#11 and #12 in this series. I've acked some of this - let me know if you would like me to apply things out of order, etc. Otherwise I'll wait. Thanks for acking/reviewing them so quickly! Let me rework and send the v2 patch series so that you can apply them one-time. OK sounds good. Can we clarify the code style side of things? Since it is a binary blob I don't feel like we are stuck with the Intel code style. We could using existing U-Boot types, change the mixed case stuff and tidy up comment style. For fsp_support.c the code doesn't look all that tidy. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] peach_pi: Add support for FIMD and DP
Add support for the eDP panel supported on peach_pi. Sjoerd Simons(1): [PATCH 1/5] Exynos5800: The Peach-Pi board does not have a Parade video bridge Ajay Kumar (4): [PATCH 2/5] arm: exynos: add display clocks for Exynos5800 [PATCH 3/5] Exynos5: Fix rpll_sdiv to support both peach-pit and peach-pi panels [PATCH 4/5] exynos5420: Add LCD and LED powerup settings for peach-pi [PATCH 5/5] peach_pi: dts: Add lcd poweron delay arch/arm/cpu/armv7/exynos/clock.c | 63 +++- arch/arm/cpu/armv7/exynos/clock_init_exynos5.c |4 +- arch/arm/dts/exynos5800-peach-pi.dts |6 +-- arch/arm/include/asm/arch-exynos/clk.h |3 ++ board/samsung/smdk5420/smdk5420.c | 32 +++- 5 files changed, 88 insertions(+), 20 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] Exynos5800: The Peach-Pi board does not have a Parade video bridge
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the
Pi. So drop it from device-tree.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
---
arch/arm/dts/exynos5800-peach-pi.dts |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/dts/exynos5800-peach-pi.dts
b/arch/arm/dts/exynos5800-peach-pi.dts
index 8aedf8e..2f9d2db 100644
--- a/arch/arm/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/dts/exynos5800-peach-pi.dts
@@ -63,11 +63,6 @@
reg = 0x20;
compatible = maxim,max98090-codec;
};
-
- edp-lvds-bridge@48 {
- compatible = parade,ps8625;
- reg = 0x48;
- };
};
sound@383 {
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] arm: exynos: add display clocks for Exynos5800
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5800 needed by
exynos video driver.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 63 +++-
arch/arm/include/asm/arch-exynos/clk.h |3 ++
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 8fab135..1a34ad6 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -1066,6 +1066,36 @@ static unsigned long exynos5420_get_lcd_clk(void)
return pclk;
}
+static unsigned long exynos5800_get_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned long sclk;
+ unsigned sel;
+ unsigned ratio;
+
+ sel = (readl(clk-src_disp10) 4) 7;
+
+ /*
+* Mapping of CLK_SRC_DISP10 CLKMUX_FIMD1 [6:4] values into
+* PLLs. The first element is a placeholder to bypass the
+* default settig.
+*/
+ const int reg_map[] = {0, CPLL, DPLL, MPLL, SPLL,
+ IPLL, EPLL, RPLL};
+ if (sel)
+ sclk = get_pll_clk(reg_map[sel]);
+ else
+ sclk = 2400;
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ ratio = readl(clk-div_disp10) 0xf;
+
+ return sclk / (ratio + 1);
+}
+
void exynos4_set_lcd_clk(void)
{
struct exynos4_clock *clk =
@@ -1197,6 +1227,31 @@ void exynos5420_set_lcd_clk(void)
writel(cfg, clk-div_disp10);
}
+void exynos5800_set_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned int cfg;
+
+ /*
+* Use RPLL for pixel clock
+* CLK_SRC_DISP10 CLKMUX_FIMD1 [6:4]
+* ==
+* 111: SCLK_RPLL
+*/
+ cfg = readl(clk-src_disp10) | (7 4);
+ writel(cfg, clk-src_disp10);
+
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ cfg = readl(clk-div_disp10);
+ cfg = ~(0xf 0);
+ cfg |= (0 0);
+ writel(cfg, clk-div_disp10);
+}
+
void exynos4_set_mipi_clk(void)
{
struct exynos4_clock *clk =
@@ -1669,8 +1724,10 @@ unsigned long get_lcd_clk(void)
if (cpu_is_exynos4())
return exynos4_get_lcd_clk();
else {
- if (proid_is_exynos5420() || proid_is_exynos5800())
+ if (proid_is_exynos5420())
return exynos5420_get_lcd_clk();
+ else if (proid_is_exynos5800())
+ return exynos5800_get_lcd_clk();
else
return exynos5_get_lcd_clk();
}
@@ -1683,8 +1740,10 @@ void set_lcd_clk(void)
else {
if (proid_is_exynos5250())
exynos5_set_lcd_clk();
- else if (proid_is_exynos5420() || proid_is_exynos5800())
+ else if (proid_is_exynos5420())
exynos5420_set_lcd_clk();
+ else
+ exynos5800_set_lcd_clk();
}
}
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index db24dc0..bf3d348 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -16,6 +16,9 @@
#define BPLL 5
#define RPLL 6
#define SPLL 7
+#define CPLL 8
+#define DPLL 9
+#define IPLL 10
#define MASK_PRE_RATIO(x) (0xff ((x 4) + 8))
#define MASK_RATIO(x) (0xf (x 4))
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] exynos5420: Add LCD and LED powerup settings for peach-pi
Add code to support powerup sequence for peach-pi LCD.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
board/samsung/smdk5420/smdk5420.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c
index a691222..915125e 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -73,19 +73,24 @@ void exynos_lcd_power_on(void)
mdelay(5);
- /* TODO(ajaykumar...@samsung.com): Use device tree */
- gpio_request(EXYNOS5420_GPIO_X35, edp_slp#);
- gpio_direction_output(EXYNOS5420_GPIO_X35, 1); /* EDP_SLP# */
- mdelay(10);
- gpio_request(EXYNOS5420_GPIO_Y77, edp_rst#);
- gpio_direction_output(EXYNOS5420_GPIO_Y77, 1); /* EDP_RST# */
- gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
- gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
- gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
-
- if (has_edp_bridge())
+ if (has_edp_bridge()) {
+ /* TODO(ajaykumar...@samsung.com): Use device tree */
+ gpio_request(EXYNOS5420_GPIO_X35, edp_slp#);
+ gpio_direction_output(EXYNOS5420_GPIO_X35, 1); /* EDP_SLP# */
+ mdelay(10);
+ gpio_request(EXYNOS5420_GPIO_Y77, edp_rst#);
+ gpio_direction_output(EXYNOS5420_GPIO_Y77, 1); /* EDP_RST# */
+ gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
+ gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
+ gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
+
if (parade_init(gd-fdt_blob))
printf(%s: ps8625_init() failed\n, __func__);
+ } else {
+ gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
+ gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
+ gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
+ }
}
void exynos_backlight_on(unsigned int onoff)
@@ -98,6 +103,11 @@ void exynos_backlight_on(unsigned int onoff)
#ifdef CONFIG_POWER_TPS65090
tps65090_fet_enable(1);
#endif
+
+ if (!has_edp_bridge()) {
+ gpio_request(EXYNOS5420_GPIO_X22, bl_en);
+ gpio_direction_output(EXYNOS5420_GPIO_X22, 1);
+ }
}
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] peach_pi: dts: Add lcd poweron delay
Add some delay after powering up the peach_pi eDP panel, to make sure the panel is ready for link training. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- arch/arm/dts/exynos5800-peach-pi.dts |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/exynos5800-peach-pi.dts b/arch/arm/dts/exynos5800-peach-pi.dts index 2f9d2db..109dab5 100644 --- a/arch/arm/dts/exynos5800-peach-pi.dts +++ b/arch/arm/dts/exynos5800-peach-pi.dts @@ -144,6 +144,7 @@ samsung,vl-vfpd = 10; samsung,vl-cmd-allow-len = 0xf; + samsung,power-on-delay = 3; samsung,winid = 3; samsung,interface-mode = 1; samsung,dp-enabled = 1; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] Exynos5: Fix rpll_sdiv to support both peach-pit and peach-pi panels
The existing setting for rpll_sdiv generates 70.5Mhz RPLL
video clock to drive 1366x768 panel on peach_pit.
This clock rate is not sufficient to drive 1920x1080 panel on peach-pi.
So, we adjust rpll_sdiv to 3 so that it generates 141Mhz pixel clock
which can drive peach-pi LCD.
This change doesn't break peach-pit LCD since 141/2=70.5Mhz, i.e FIMD
divider at IP level will get set to 1(the required divider setting
will be calculated and set by exynos_fimd_set_clock()) and hence
peach-pit LCD still works fine.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock_init_exynos5.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
index 0aff3d0..0200fd1 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
+++ b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
@@ -179,10 +179,10 @@ struct mem_timings mem_timings[] = {
.spll_mdiv = 0xc8,
.spll_pdiv = 0x3,
.spll_sdiv = 0x2,
- /* RPLL @70.5Mhz */
+ /* RPLL @141Mhz */
.rpll_mdiv = 0x5E,
.rpll_pdiv = 0x2,
- .rpll_sdiv = 0x4,
+ .rpll_sdiv = 0x3,
.direct_cmd_msr = {
0x00020018, 0x0003, 0x00010046, 0x0d70,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/25] x86: Add Intel Queensbay platform support
Hi Simon, On Fri, Dec 5, 2014 at 10:16 PM, Simon Glass s...@chromium.org wrote: Hi Bin, On 5 December 2014 at 07:07, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Dec 5, 2014 at 8:04 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:00, Bin Meng bmeng...@gmail.com wrote: This patch series add the Intel Queensbay platform support. The Queensbay platform includes an Atom E6xx processor (codename Tunnel Creek) and a Platform Controller Hub EG20T (codename Topcliff). The support depends on Intel Firmware Support Package (FSP) to initialize the processor and chipset including system memory. With this patch series, U-Boot boots to Linux kernel. Validated on an Intel Crown Bay board with kernel 3.17. Note I did not clean up the original FSP codes released by Intel with U-Boot coding convention. So there will be coding style issues reported by the patch checkers against patch#11 and #12 in this series. I've acked some of this - let me know if you would like me to apply things out of order, etc. Otherwise I'll wait. Thanks for acking/reviewing them so quickly! Let me rework and send the v2 patch series so that you can apply them one-time. OK sounds good. Can we clarify the code style side of things? Since it is a binary blob I don't feel like we are stuck with the Intel code style. We could using existing U-Boot types, change the mixed case stuff and tidy up comment style. For fsp_support.c the code doesn't look all that tidy. Yes, I will update the code style in the FSP codes to use U-Boot style. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] Exynos5800: The Peach-Pi board does not have a Parade video bridge
Hi All, On Tue, Dec 2, 2014 at 2:00 AM, Simon Glass s...@chromium.org wrote: Hi Sjoerd, On 1 December 2014 at 13:25, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: On Mon, 2014-12-01 at 13:09 -0700, Simon Glass wrote: +Akshay Hi Sjoerd, On 1 December 2014 at 03:03, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Hey Simon, On Sun, 2014-11-30 at 11:56 -0700, Simon Glass wrote: On 27 November 2014 at 08:08, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: Unlike the Peach-Pit board, there is no parade edp to lvds bridge on the Pi. So drop it from device-tree Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- Changes since v1: Only modify the DTB arch/arm/dts/exynos5800-peach-pi.dts | 5 - 1 file changed, 5 deletions(-) Acked-by: Simon Glass s...@chromium.org Tested on snow, pit, pi (display does not yet work on Pi). Just to be clear, in your testing does the display not work on Pi? It seems to be ok here (with u-boot starting chainloaded from one of the KERN partitions) That's right, not in U-Boot. I think this is because some GPIOs need to be enabled to turn on the backlight etc. Maybe you have an EC which turns these on automatically? If current mainline is supposed to make the display work on Pi then I need to do some debugging. Please let me know. It does work on my machine, so i was wondering if it's a setup difference. I'm using the chained u-boot method (iotw the standard chromeos u-boot in flash starts main-line u-boot from mmc/SD), which might well mean that the GPIOs you're referring to are still turned on by the first u-boot (which it has to do to show me the unverified boot warning screen)? Yes that's right. Maybe Akshay / Ajay have ideas, or otherwise I can add this. I think it is two GPIOs, but it might be TPSCHROME also. Now, I have added support for peach_pi display in u-boot. Kindly check the patches. Ajay ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/11] dm: i2c: Add a uclass for I2C
Hi Masahiro,
On 5 December 2014 at 06:11, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Simon,
Here are some comments on v4.
On Thu, 4 Dec 2014 21:21:20 -0700
Simon Glass s...@chromium.org wrote:
+#define I2C_MAX_OFFSET_LEN 4
+
+/**
+ * i2c_setup_offset() - Set up a new message with a chip offset
+ *
+ * @chip:Chip to use
+ * @offset: Byte offset within chip
+ * @offset_buf: Place to put byte offset
+ * @msg: Message buffer
+ * @return 0 if OK, -EADDRNOTAVAIL if the offset length is 0. In that case
the
+ * message is still set up but will not contain an offset.
+ */
+static int i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
+ uint8_t offset_buf[], struct i2c_msg *msg)
+{
+ int offset_len;
+
+ msg-addr = chip-chip_addr;
+ msg-flags = chip-flags DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
+ msg-len = chip-offset_len;
+ msg-buf = offset_buf;
+ if (!chip-offset_len)
+ return -EADDRNOTAVAIL;
I notice i2c_{read|write}_bytewise checks the return code of this
function, but the normal one does not.
I think it seems a little bit strange.
Instead of the code above, can we put this here?
if (chip-offset_len I2C_MAX_OFFSET_LEN)
return -EADDRNOTAVAIL;
And then, the normal i2c_{read|write} should also check the return code of
this.
if (!chip-offset_len)
return -EADDRNOTAVAIL;
is specific to *_bytewise ones, so it can be moved to there.
We are not trying to check that the offset length is too large - that
has already been done in ic_set_chip_offset_len(). I will add an
assert and a comment. The purpose of the return value is to indicate
whether an offset was added at all. In the case of a chip with a zero
offset length, when doing a read, we want to omit the 'write' cycle
entirely since there is no offset to write. The return value makes
that possible.
+ offset_len = chip-offset_len;
+ while (offset_len--)
+ *offset_buf++ = offset (8 * offset_len);
We should be very careful about this code
because buffer overrun happens if too big offset_len is given.
So, we should make sure that offset_len is no larger than I2C_MAX_OFFSET_LEN.
(Or, you can pass the length of offset_buf[] to this function.)
I know you implemented a similar check check in i2c_set_chip_offset_len()
function.
But users can skip i2c_set_chip_offset_len() and
directly invoke i2c_read() or i2c_write().
This is very dangerous.
If they skip it, then the value will be 1, the default. I've added an
assert() but I don't really want to bloat the code which duplicate
checks. Of course assert() is only useful for debugging.
+int i2c_write(struct udevice *dev, uint offset, const uint8_t *buffer, int
len)
+{
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ struct udevice *bus = dev_get_parent(dev);
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[1];
+
+ if (!ops-xfer)
+ return -ENOSYS;
+
+ if (chip-flags DM_I2C_CHIP_RE_ADDRESS)
+ return i2c_write_bytewise(dev, offset, buffer, len);
Have you noticed that do_i2c_write() function in common/cmd_i2c.c
always does the bytewise-equivalent behavior?
(It uses a while() loop and in each loop it calls i2c_write with length=1)
Yes, in fact someone submitted a patch for this recently.
http://patchwork.ozlabs.org/patch/415117/
I'd like to use the flags to support this at some point.
On the other hand, do_i2c_read() does not split it into small chunks.
At first I was wondering why only do_i2c_write() must split into many
small transactions, but I got an answer when I was testing it on my board.
My on-board EEPROM chip does not work with long-burst write,
but it works with any long-burst read.
It turned out some chips (at least mine) require DM_I2C_CHIP_RE_ADDRESS
only for write.
Maybe, do we need to have a _RE_ADDRESS flag for each of write/read?
I was heading that way originally but then stopped when I wasn't sure
of the use case. I think I will do this.
+static int i2c_probe_chip(struct udevice *bus, uint chip_addr,
+ enum dm_i2c_chip_flags flags)
I notice you added flags argument in v4.
When and how do we use this flag ?
for DM_I2C_CHIP_10BIT ??
I commented the exported function i2c_probe() but not this, I'll add a comment.
+{
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[1];
+ uint8_t ch = 0;
+ int ret;
+
+ if (ops-probe_chip) {
+ ret = ops-probe_chip(bus, chip_addr, flags);
+ if (!ret || ret != -ENOSYS)
+ return ret;
+ }
+
+ if (!ops-xfer)
+ return -ENOSYS;
+
+ /* Probe with a zero-length message */
+ msg-addr = chip_addr;
+ msg-flags = 0;
If my guess is correct, this line should be like this?
Re: [U-Boot] [PATCH v4 11/11] dm: i2c: tegra: Convert to driver model
Hi Masahiro,
On 5 December 2014 at 06:15, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Simon,
On Thu, 4 Dec 2014 21:21:30 -0700
Simon Glass s...@chromium.org wrote:
+static const struct dm_i2c_ops tegra_i2c_ops = {
+ .xfer = tegra_i2c_xfer,
+ .probe_chip = tegra_i2c_probe_chip,
+ .set_bus_speed = tegra_i2c_set_bus_speed,
+};
- for (i = 0; i TEGRA_I2C_NUM_CONTROLLERS; i++) {
- struct i2c_bus *bus = i2c_controllers[i];
+static int tegra_i2c_child_pre_probe(struct udevice *dev)
+{
+ struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
- if (bus-inited bus-is_dvc)
- return i;
- }
+ if (dev-of_offset == -1)
+ return 0;
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
+i2c_chip);
+}
As I said in v3, it is unfortunate that uclass does not support
.child_pre_probe.
sandbox_i2c.c and tegra-i2c.c have a similar .child_pre_probe.
I copied tegra_i2c_child_pre_probe() to my i2c driver verbatim.
I guess every driver will do so.
Is it a good idea to move .child_pre_probe to uclass_driver?
Sorry I didn't reply on this.
I have been thinking about this for a while. For SPI we have the same
problem and I think I mentioned it in the code somewhere. For the PCI
RFC I have already adjusted the platdata lifecycle a little since I
think it will simplify all buses, and have added a another data
pointer for a different purpose.
For the case you raise the problem as you say is that each driver is
required to provide a certain structure for its children so that its
uclass is happy. On the other hand the driver may want to add
additional information We already have a lot of flexibility so I was
waiting to see how much this would really matter (there is after all a
complexity trade-off).
With PCI I've made some changes and I think I'll end up adding another
pointer. At that point I will also want to change SPI and I2C.
For now, I'd like to leave this alone. It does work and avoids adding
new features at this late stage.
Let's revisit when I come back to PCI.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 01/11] arm: omap5: don't enable misc_init_r by default
On Thu, Nov 06, 2014 at 08:28:42AM -0600, Felipe Balbi wrote: Out of all OMAP5-like boards, only one of them needs CONFIG_MISC_INIT_R, so it's best to enable that for that particular board only, instead of enabling for all boards unconditionally. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 02/11] arm: omap5: tps659038: rename regulator defines
On Thu, Nov 06, 2014 at 08:28:43AM -0600, Felipe Balbi wrote: Those regulators don't have any coupling with what they supply, so remove the suffixes in order to not confuse anybody. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 03/11] arm: dra7xx: prcm: add missing registers
On Thu, Nov 06, 2014 at 08:28:44AM -0600, Felipe Balbi wrote: some boards might want to use USB1 for host, without fiddling those registers it'll be impossible. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 04/11] usb: phy: omap_usb_phy: fix build breakage
On Thu, Nov 06, 2014 at 08:28:45AM -0600, Felipe Balbi wrote: there's no such function usb3_phy_power(), it's likely that author meant to call, usb_phy_power() instead, but that's already called properly from xhci-omap.c. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 05/11] arm: omap-common: emif: allow to map memory without interleaving
On Thu, Nov 06, 2014 at 08:28:46AM -0600, Felipe Balbi wrote: If we want to have two sections, one on each EMIF, without interleaving, current code wouldn't enable emif2. Fix that problem. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 08/11] arm: omap5: sdram: mark emif_get_ext_phy_ctrl_const_regs __weak
On Thu, Nov 06, 2014 at 08:28:49AM -0600, Felipe Balbi wrote: this will allow for boards to overwrite those in case memory setup is different. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, v4, 1/3] mmc: Board-specific MMC power initializations
On Sat, Nov 08, 2014 at 08:55:45PM +0100, Paul Kocialkowski wrote: Some devices may use non-standard combinations of regulators to power MMC: this allows these devices to provide a board-specific MMC power init function to set everything up in their own way. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 10/11] arm: omap: add support for am57xx devices
On Thu, Nov 06, 2014 at 08:28:51AM -0600, Felipe Balbi wrote: just add a few ifdefs around because this device is very similar to dra7xxx. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, v4, 2/3] twl4030: device-index-specific MMC power initializations, common ramp-up delay
On Sat, Nov 08, 2014 at 08:55:46PM +0100, Paul Kocialkowski wrote: Not every device has multiple MMC slots available, so it makes sense to enable only the required LDOs for the available slots. Generic code in omap_hsmmc will enable both VMMC1 and VMMC2, in doubt. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot,07/11] arm: omap5: make hw_init_data weak
On Thu, Nov 06, 2014 at 08:28:48AM -0600, Felipe Balbi wrote: this way we can let boards overwrite based on what they need. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 09/11] arm: omap_common: expose tps659038 and dra7xx_dplls
On Thu, Nov 06, 2014 at 08:28:50AM -0600, Felipe Balbi wrote: expose those two definitions so they can be used by another board which we're adding in upcoming patches. Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, 06/11] configs: omap5_common : Boot rootfs from sd card by default
On Thu, Nov 06, 2014 at 08:28:47AM -0600, Felipe Balbi wrote: From: Franklin S Cooper Jr fcoo...@ti.com * Since the emmc isn't always programed trying to load the fs from the emmc causes boot failures/kernel panic. * The current bootcmd is set to: bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; \ setenv mmcroot /dev/mmcblk0p2 rw; run mmcboot; My guess is the env variables should be set so that sd card boot (dt,kernel,fs) is the default and then fallback to emmc if it fails (no sd card detected) The current bootcmd attempts to set mmcroot to the sd card rootfs but that code doesn't run due to mmcboot being ran early on. Signed-off-by: Franklin Cooper Jr. fcoo...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] Fix for ns16550 driver hanging on OMAP4
On Mon, Nov 10, 2014 at 11:04:10AM -0800, Gregoire Gentil wrote: Here is a patch to apply the same fix on OMAP4 boards as on OMAP3, in order to prevent ns16550 hanging during SPL boot, Grégoire mode before * SPL starts only THRE bit is set. We have to empty the transmitter * before initialization starts. */ Grégoire diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c index 8f05191..a1d3781 100644 Applied to u-boot-ti/master after re-wordding commit message, 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] [U-Boot, v3, 11/11] beagle_x15: add board support for Beagle x15
On Mon, Nov 10, 2014 at 02:02:44PM -0600, Felipe Balbi wrote: BeagleBoard-X15 is the next generation Open Source Hardware BeagleBoard based on TI's AM5728 SoC featuring dual core 1.5GHZ A15 processor. The platform features 2GB DDR3L (w/dual 32bit busses), eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60), separate LCD port, video In port, 4GB eMMC, uSD, Analog audio in/out, dual 1G Ethernet. For more information, refer to: http://www.elinux.org/Beagleboard:BeagleBoard-X15 Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] arm: am33xx: Handle NAND+I2C boot-device the same way as NAND
On Wed, Nov 12, 2014 at 11:57:33AM +0100, Stefan Roese wrote: Re-map NANDI2C boot-device to the normal NAND boot-device. Otherwise the SPL boot IF can't handle this device correctly. Somehow booting with Hynix 4GBit NAND H27U4G8 on Siemens Draco leads to this boot-device passed to SPL from the BootROM. With this change, Draco boots just fine into main U-Boot. Signed-off-by: Stefan Roese s...@denx.de Cc: Tom Rini tr...@ti.com Cc: Roger Meier r.me...@siemens.com Cc: Samuel Egli samuel.e...@siemens.com Applied to u-boot-ti/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] ARM: OMAP5: DRA7xx: Fix misleading comments in mux_data.h
On Mon, Nov 10, 2014 at 06:34:10PM +0200, Lubomir Popov wrote: The comments on the QSPI pad assignments erronously swapped the qspi1_d0 and qspi1_d1 functionality and could cause confusion. QSPI1_D[0] is in fact muxed on pad U1 (gpmc_a16), and QSPI1_D[1] - on pad P3 (gpmc_a17). Fixing comments. Signed-off-by: Lubomir Popov l-po...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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] [U-Boot, v1, 1/3] arm, am335x, siemens: fix factoryset interpretation
On Tue, Nov 18, 2014 at 11:51:04AM +0100, Heiko Schocher wrote: a record could contain other records, so after an (begin mark) there not always come an end mark , instead a is possible. Take care of this. Signed-off-by: Heiko Schocher h...@denx.de Applied to u-boot-ti/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] [U-Boot, v2] mtd: nand: omap_gpmc: Always use ready/busy pin
On Thu, Nov 13, 2014 at 03:43:39AM +0100, Stefan Roese wrote: The functions to detect the state of the ready / busy signal is already available but only used in the SPL case. Lets use it always, also for the main U-Boot. As all boards should have this HW connection. Testing on Siemens Draco (am335x) showed a small perfomance gain by using this ready pin to detect the NAND chip state. Here the values tested on Draco with Hynix 4GBit NAND: Without NAND ready pin: U-Boot# time nand read 8040 0 40 NAND read: device 0 offset 0x0, size 0x40 4194304 bytes read: OK time: 2.947 seconds, 2947 ticks With NAND ready pin: U-Boot# time nand read 8040 0 40 NAND read: device 0 offset 0x0, size 0x40 4194304 bytes read: OK time: 2.795 seconds, 2795 ticks So an increase of approx. 5%. Signed-off-by: Stefan Roese s...@denx.de Cc: Tom Rini tr...@ti.com Cc: Scott Wood scottw...@freescale.com Cc: Roger Meier r.me...@siemens.com Cc: Samuel Egli samuel.e...@siemens.com Applied to u-boot-ti/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] ARM: OMAP5: DRA7xx: Enable 8-bit eMMC access on the dra7xx_evm
On Mon, Nov 10, 2014 at 06:14:18PM +0200, Lubomir Popov wrote: Tested on a Vayu EVM Rev.E2 with DRA752 ES1.1 Signed-off-by: Lubomir Popov l-po...@ti.com Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/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 19/25] x86: Add crownbay defconfig and config.h
Hi Bin,
On 5 December 2014 at 06:53, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Dec 5, 2014 at 7:56 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:03, Bin Meng bmeng...@gmail.com wrote:
Signed-off-by: Bin Meng bmeng...@gmail.com
---
configs/crownbay_defconfig | 6 ++
include/configs/crownbay.h | 52
++
2 files changed, 58 insertions(+)
create mode 100644 configs/crownbay_defconfig
create mode 100644 include/configs/crownbay.h
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
new file mode 100644
index 000..ce90553
--- /dev/null
+++ b/configs/crownbay_defconfig
@@ -0,0 +1,6 @@
+CONFIG_SYS_EXTRA_OPTIONS=SYS_TEXT_BASE=0xfff0
+CONFIG_X86=y
+CONFIG_TARGET_CROWNBAY=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_SEPARATE=y
+CONFIG_DEFAULT_DEVICE_TREE=crownbay
diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h
new file mode 100644
index 000..2314e62
--- /dev/null
+++ b/include/configs/crownbay.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * board/config.h - configuration options, board specific
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include configs/x86-common.h
+
+#define CONFIG_SYS_MONITOR_LEN (1 20)
+#define CONFIG_SYS_X86_START16 0xf800
+#define CONFIG_BOARD_EARLY_INIT_F
+
+#define CONFIG_X86_RESET_VECTOR
+#define CONFIG_NR_DRAM_BANKS 1
+
+#define CONFIG_COREBOOT_SERIAL
Do you think you could create a patch to rename this to x86_serial?
Sure, I can.
+#define CONFIG_SMSC_LPC47M
+
+#define CONFIG_PCI_MEM_BUS 0x4000
+#define CONFIG_PCI_MEM_PHYSCONFIG_PCI_MEM_BUS
+#define CONFIG_PCI_MEM_SIZE0x8000
+
+#define CONFIG_PCI_PREF_BUS0xc000
+#define CONFIG_PCI_PREF_PHYS CONFIG_PCI_PREF_BUS
+#define CONFIG_PCI_PREF_SIZE 0x2000
+
+#define CONFIG_PCI_IO_BUS 0x2000
+#define CONFIG_PCI_IO_PHYS CONFIG_PCI_IO_BUS
+#define CONFIG_PCI_IO_SIZE 0xe000
+
+#define CONFIG_SYS_EARLY_PCI_INIT
+#define CONFIG_PCI_PNP
+
+#define CONFIG_STD_DEVICES_SETTINGS stdin=serial\0 \
+ stdout=serial\0 \
+ stderr=serial\0
+
+#define CONFIG_SCSI_DEV_LIST\
+ {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SATA}
+
+/* Video is not supported */
+#undef CONFIG_VIDEO
+#undef CONFIG_CFB_CONSOLE
Why is video not supported?
Tunnel Creek has one GPU integrated, but on my Crown Bay board, the
output siginal is routed to LVDS to be connected to an external LCD,
which I don't have for now. There is no public datasheet describing
the details about the integrated GPU, neither did I found a legacy
video ROM supporting that. There seems to be a UEFI native graphics
driver from Intel, but that means I will need study that and write a
U-Boot native graphics driver, which needs some time. Maybe supporting
PCIe based graphics card is an option, and I will find some time to
try that.
I'm not so worried about PCIe-based graphics, although it might mostly
work with a big of tweaking, since we can find and execute ROMs.
But for built-in graphics I would like to support it. This is a key
feature, and I hope there will be common elements. between the boards.
Similarly with things like USB, Ethernet, SD card which you have
addressed.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1, 3/3] arm, am335x: siemens boards add FIT support
On Tue, Nov 18, 2014 at 11:51:06AM +0100, Heiko Schocher wrote: add FIT support and set boardid from factoryset records DEV/id and COMP/ver. boardid is used for selecting which fit configuration gets booted on the board. Signed-off-by: Heiko Schocher h...@denx.de Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello myself, The following changes since commit f0c6e1c31b94f193047619b6adf67c2d792b659e: Revert image-fdt: boot_get_fdt() return value when no DTB exists (2014-12-03 13:19:34 -0500) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 956a8bae537974673e126f67a227355f27e48ec6: ns16550.c: Fix for ns16550 driver hanging on OMAP4 (2014-12-04 21:28:32 -0500) Felipe Balbi (10): arm: omap5: don't enable misc_init_r by default arm: omap5: tps659038: rename regulator defines arm: dra7xx: prcm: add missing registers usb: phy: omap_usb_phy: fix build breakage arm: omap-common: emif: allow to map memory without interleaving arm: omap5: make hw_init_data weak arm: omap5: sdram: mark emif_get_ext_phy_ctrl_const_regs __weak arm: omap_common: expose tps659038 and dra7xx_dplls arm: omap: add support for am57xx devices beagle_x15: add board support for Beagle x15 Franklin S Cooper Jr (1): configs: omap5_common : Boot rootfs from sd card by default Gregoire Gentil (1): ns16550.c: Fix for ns16550 driver hanging on OMAP4 Heiko Schocher (3): arm, am335x, siemens: fix factoryset interpretation arm, am335x, siemens: read COMP/ver from factoryset arm, am335x: siemens boards add FIT support Lubomir Popov (2): ARM: OMAP5: DRA7xx: Enable 8-bit eMMC access on the dra7xx_evm ARM: OMAP5: DRA7xx: Fix misleading comments in mux_data.h Paul Kocialkowski (3): mmc: Board-specific MMC power initializations twl4030: device-index-specific MMC power initializations, common ramp-up delay omap_hsmmc: Board-specific TWL4030 MMC power initializations Stefan Roese (2): arm: am33xx: Handle NAND+I2C boot-device the same way as NAND mtd: nand: omap_gpmc: Always use ready/busy pin arch/arm/cpu/armv7/omap-common/boot-common.c | 17 +- arch/arm/cpu/armv7/omap-common/emif-common.c |9 +- arch/arm/cpu/armv7/omap5/Kconfig |4 + arch/arm/cpu/armv7/omap5/hw_data.c | 12 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |3 + arch/arm/cpu/armv7/omap5/sdram.c |2 +- arch/arm/include/asm/arch-am33xx/spl.h |1 + arch/arm/include/asm/arch-omap5/clock.h | 12 +- arch/arm/include/asm/arch-omap5/omap.h |4 +- arch/arm/include/asm/omap_common.h |3 + board/comelit/dig297/dig297.c|5 + board/compulab/cm_t35/cm_t35.c |7 + board/corscience/tricorder/tricorder.c |7 + board/isee/igep00x0/igep00x0.c |7 + board/logicpd/omap3som/omap3logic.c |7 + board/logicpd/zoom1/zoom1.c |5 + board/matrix_vision/mvblx/mvblx.c|6 + board/nokia/rx51/rx51.c |6 + board/overo/overo.c |7 + board/pandora/pandora.c |5 + board/siemens/common/board.c |9 - board/siemens/common/factoryset.c| 52 ++-- board/siemens/common/factoryset.h|2 + board/siemens/draco/board.c |9 + board/siemens/pxm2/board.c | 34 +++ board/siemens/rut/board.c| 23 ++ board/technexion/tao3530/tao3530.c |7 + board/ti/beagle/beagle.c |7 + board/ti/beagle_x15/Kconfig | 12 + board/ti/beagle_x15/Makefile |8 + board/ti/beagle_x15/board.c | 395 ++ board/ti/beagle_x15/mux_data.h | 55 board/ti/dra7xx/evm.c| 12 - board/ti/dra7xx/mux_data.h |4 +- board/ti/evm/evm.c |8 + board/ti/sdp3430/sdp.c |5 + board/timll/devkit8000/devkit8000.c |7 + configs/beagle_x15_defconfig |5 + drivers/mmc/mmc.c|7 + drivers/mmc/omap_hsmmc.c | 12 +- drivers/mtd/nand/omap_gpmc.c |9 +- drivers/power/palmas.c |2 +- drivers/power/twl4030.c | 28 +- drivers/serial/ns16550.c |9 +- drivers/spi/ti_qspi.c|8 +- drivers/usb/phy/omap_usb_phy.c |2 - include/configs/beagle_x15.h | 88 ++ include/configs/cm_t54.h |1 - include/configs/dra7xx_evm.h |1 + include/configs/omap5_uevm.h |1 + include/configs/pxm2.h |4 + include/configs/rut.h|4 + include/configs/ti_omap5_common.h|5 +- include/linux/usb/xhci-omap.h|4 + include/mmc.h
Re: [U-Boot] [U-Boot, v1, 2/3] arm, am335x, siemens: read COMP/ver from factoryset
On Tue, Nov 18, 2014 at 11:51:05AM +0100, Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de Applied to u-boot-ti/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] [U-Boot, v4, 3/3] omap_hsmmc: Board-specific TWL4030 MMC power initializations
On Sat, Nov 08, 2014 at 08:55:47PM +0100, Paul Kocialkowski wrote: Boards using the TWL4030 regulator may not all use the LDOs the same way (e.g. MMC2 power can be controlled by another LDO than VMMC2). This delegates TWL4030 MMC power initializations to board-specific functions, that may still call twl4030_power_mmc_init for the default behavior. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Reviewed-by: Tom Rini tr...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/9] ARM: UniPhier: move support card select to Kconfig
There are two kinds of expansion boards which are often used for the UniPhier platform and they are only exclusively selectable. It can be better described by the choice menu of Kconfig. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/cpu/armv7/uniphier/Kconfig | 23 +++ configs/ph1_ld4_defconfig | 1 + configs/ph1_pro4_defconfig | 1 + configs/ph1_sld8_defconfig | 1 + include/configs/ph1_ld4.h | 15 --- include/configs/ph1_pro4.h | 15 --- include/configs/ph1_sld8.h | 15 --- include/configs/uniphier-common.h | 6 -- 8 files changed, 26 insertions(+), 51 deletions(-) diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index 31a03d9..1d96db2 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -27,6 +27,29 @@ config MACH_PH1_SLD8 endchoice +choice + prompt UniPhier Support Card select + optional + +config PFC_MICRO_SUPPORT_CARD + bool Support card with PFC CPLD + help + This option provides support for the expansion board with PFC + original address mapping. + + Say Y to use the on-board UART, Ether, LED devices. + +config DCC_MICRO_SUPPORT_CARD + bool Support card with DCC CPLD + help + This option provides support for the expansion board with DCC- + arranged address mapping that is compatible with legacy UniPhier + reference boards. + + Say Y to use the on-board UART, Ether, LED devices. + +endchoice + config CMD_PINMON bool Enable boot mode pins monitor command depends on !SPL_BUILD diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig index de068e9..3155340 100644 --- a/configs/ph1_ld4_defconfig +++ b/configs/ph1_ld4_defconfig @@ -4,6 +4,7 @@ CONFIG_FIT_VERBOSE=y +S:CONFIG_ARM=y +S:CONFIG_ARCH_UNIPHIER=y +S:CONFIG_MACH_PH1_LD4=y ++S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig index f4ddf5f..7ea4e6e 100644 --- a/configs/ph1_pro4_defconfig +++ b/configs/ph1_pro4_defconfig @@ -4,6 +4,7 @@ CONFIG_FIT_VERBOSE=y +S:CONFIG_ARM=y +S:CONFIG_ARCH_UNIPHIER=y +S:CONFIG_MACH_PH1_PRO4=y ++S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig index ee14382..ddf210c 100644 --- a/configs/ph1_sld8_defconfig +++ b/configs/ph1_sld8_defconfig @@ -4,6 +4,7 @@ CONFIG_FIT_VERBOSE=y +S:CONFIG_ARM=y +S:CONFIG_ARCH_UNIPHIER=y +S:CONFIG_MACH_PH1_SLD8=y ++S:CONFIG_DCC_MICRO_SUPPORT_CARD=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BDI=y CONFIG_CMD_CONSOLE=y diff --git a/include/configs/ph1_ld4.h b/include/configs/ph1_ld4.h index 73a95e6..a3e4f96 100644 --- a/include/configs/ph1_ld4.h +++ b/include/configs/ph1_ld4.h @@ -9,21 +9,6 @@ #define __PH1_XXX_H /* - * Support Card Select - * - * CONFIG_PFC_MICRO_SUPPORT_CARD - Original Micro Support Card made by PFC. - * CONFIG_DCC_MICRO_SUPPORT_CARD - DCC version Micro Support Card. - * CPLD is re-programmed for ARIMA board compatibility. - * No define - No support card. - */ - -#if 0 -#define CONFIG_PFC_MICRO_SUPPORT_CARD -#else -#define CONFIG_DCC_MICRO_SUPPORT_CARD -#endif - -/* * Serial Configuration * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL diff --git a/include/configs/ph1_pro4.h b/include/configs/ph1_pro4.h index 7780030..15849ba 100644 --- a/include/configs/ph1_pro4.h +++ b/include/configs/ph1_pro4.h @@ -9,21 +9,6 @@ #define __PH1_XXX_H /* - * Support Card Select - * - * CONFIG_PFC_MICRO_SUPPORT_CARD - Original Micro Support Card made by PFC. - * CONFIG_DCC_MICRO_SUPPORT_CARD - DCC version Micro Support Card. - * CPLD is re-programmed for ARIMA board compatibility. - * No define - No support card. - */ - -#if 0 -#define CONFIG_PFC_MICRO_SUPPORT_CARD -#else -#define CONFIG_DCC_MICRO_SUPPORT_CARD -#endif - -/* * Serial Configuration * SoC UART : enable CONFIG_UNIPHIER_SERIAL * On-board UART: enable CONFIG_SYS_NS16550_SERIAL diff --git a/include/configs/ph1_sld8.h b/include/configs/ph1_sld8.h index e2f1102..e64d902 100644 --- a/include/configs/ph1_sld8.h +++ b/include/configs/ph1_sld8.h @@ -9,21 +9,6 @@ #define __PH1_XXX_H /* - * Support Card Select - * - * CONFIG_PFC_MICRO_SUPPORT_CARD - Original Micro Support Card made by PFC. - * CONFIG_DCC_MICRO_SUPPORT_CARD - DCC version Micro Support Card. - * CPLD is re-programmed for ARIMA board compatibility. - * No define - No support card. - */ - -#if 0 -#define CONFIG_PFC_MICRO_SUPPORT_CARD -#else -#define CONFIG_DCC_MICRO_SUPPORT_CARD -#endif -
[U-Boot] [PATCH 6/9] ARM: UniPhier: add more device nodes to device tree
Add I2C controller and NAND controller devices. Fix indentation too.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/dts/uniphier-ph1-ld4-ref.dts | 23 +---
arch/arm/dts/uniphier-ph1-ld4.dtsi | 40 -
arch/arm/dts/uniphier-ph1-pro4-ref.dts | 26 +++---
arch/arm/dts/uniphier-ph1-pro4.dtsi| 64 +-
arch/arm/dts/uniphier-ph1-sld8-ref.dts | 23 +---
arch/arm/dts/uniphier-ph1-sld8.dtsi| 40 -
6 files changed, 201 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index f01189c..5d63a9a 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -23,20 +23,35 @@
bootargs = console=ttyPS0,115200 earlyprintk;
stdout-path = uart0;
};
+
+ aliases {
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
};
uart0 {
- status = okay;
+ status = okay;
};
uart1 {
- status = okay;
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible = i2c-eeprom;
+ reg = 0x50;
+ };
};
usb0 {
- status = okay;
+ status = okay;
};
usb1 {
- status = okay;
+ status = okay;
};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index 80074c5..8c217b8 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -13,8 +13,8 @@
compatible = panasonic,ph1-ld4;
cpus {
- #size-cells = 0;
#address-cells = 1;
+ #size-cells = 0;
cpu@0 {
device_type = cpu;
@@ -57,6 +57,38 @@
clock-frequency = 36864000;
};
+ i2c0: i2c@5840 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5840 0x40;
+ status = disabled;
+ };
+
+ i2c1: i2c@5848 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5848 0x40;
+ status = disabled;
+ };
+
+ i2c2: i2c@5850 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5850 0x40;
+ status = disabled;
+ };
+
+ i2c3: i2c@5858 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5858 0x40;
+ status = disabled;
+ };
+
usb0: usb@5a800100 {
compatible = panasonic,uniphier-ehci, usb-ehci;
status = disabled;
@@ -74,5 +106,11 @@
status = disabled;
reg = 0x5a820100 0x100;
};
+
+ nand: nand@6800 {
+ compatible = denali,denali-nand-dt;
+ reg = 0x6800 0x20, 0x6810 0x1000;
+ reg-names = nand_data, denali_reg;
+ };
};
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 52fa81f..dab01da 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -23,20 +23,38 @@
bootargs = console=ttyPS0,115200 earlyprintk;
stdout-path = uart0;
};
+
+ aliases {
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ i2c4 = i2c4;
+ i2c5 = i2c5;
+ i2c6 = i2c6;
+ };
};
uart0 {
- status = okay;
+ status = okay;
};
uart1 {
- status = okay;
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible = i2c-eeprom;
+ reg = 0x50;
+ };
};
usb0 {
- status = okay;
+ status = okay;
};
usb1 {
- status = okay;
+ status = okay;
};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index dd84269..debe9cb 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -13,8 +13,8 @@
compatible = panasonic,ph1-pro4;
cpus {
- #size-cells = 0;
#address-cells = 1;
[U-Boot] [PATCH 1/9] ARM: UniPhier: disable autostart by default
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- include/configs/uniphier-common.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/configs/uniphier-common.h b/include/configs/uniphier-common.h index 2140fcc..31ab470 100644 --- a/include/configs/uniphier-common.h +++ b/include/configs/uniphier-common.h @@ -205,7 +205,6 @@ are defined. Select only one of them. image_offset=0x0008\0 \ image_size=0x00f0\0 \ verify=n\0\ - autostart=yes\0 \ norboot=run add_default_bootargs; \ bootm $image_offset\0 \ nandboot=run add_default_bootargs;\ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/9] ARM: UniPhier: extend register area of init page table for PH1-sLD3
0x2000-0x2fff: assigned to ARM mpcore (sLD3 only) 0xf000-0x: assigned to Denali NAND controller (sLD3 only) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/cpu/armv7/uniphier/init_page_table.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/uniphier/init_page_table.c b/arch/arm/cpu/armv7/uniphier/init_page_table.c index d273835..a0d10a9 100644 --- a/arch/arm/cpu/armv7/uniphier/init_page_table.c +++ b/arch/arm/cpu/armv7/uniphier/init_page_table.c @@ -28,7 +28,12 @@ #define IS_SSC(x) ((IS_SPL_TEXT_AREA(x)) || \ (IS_INIT_STACK_AREA(x))) #define IS_EXT(x) ((x) 0x100) -#define IS_REG(x) (0x500 = (x) (x) 0x700) + +/* 0x2000-0x2fff, 0xf000-0x are only used by PH1-sLD3 */ +#define IS_REG(x) (0x200 = (x) (x) 0x300) || \ + (0x500 = (x) (x) 0x700) || \ + (0xf00 = (x)) + #define IS_DDR(x) (0x800 = (x) (x) 0xf00) #define MMU_FLAGS(x) (IS_SSC(x)) ? SSC : \ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/9] ARM: UniPhier: merge UniPhier config headers into a single file
Some configurations have been moved to Kconfig and the difference
among the config headers of UniPhier SoC variants is getting smaller
and smaller. Now is a good time to merge them into a single file.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/armv7/uniphier/Kconfig | 4 +-
include/configs/ph1_ld4.h | 38 --
include/configs/ph1_pro4.h| 38 --
include/configs/ph1_sld8.h| 40 ---
include/configs/{uniphier-common.h = uniphier.h} | 47 +++
5 files changed, 48 insertions(+), 119 deletions(-)
delete mode 100644 include/configs/ph1_ld4.h
delete mode 100644 include/configs/ph1_pro4.h
delete mode 100644 include/configs/ph1_sld8.h
rename include/configs/{uniphier-common.h = uniphier.h} (86%)
diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig
b/arch/arm/cpu/armv7/uniphier/Kconfig
index 1d96db2..9760299 100644
--- a/arch/arm/cpu/armv7/uniphier/Kconfig
+++ b/arch/arm/cpu/armv7/uniphier/Kconfig
@@ -5,9 +5,7 @@ config SYS_SOC
default uniphier
config SYS_CONFIG_NAME
- default ph1_pro4 if MACH_PH1_PRO4
- default ph1_ld4 if MACH_PH1_LD4
- default ph1_sld8 if MACH_PH1_SLD8
+ default uniphier
config UNIPHIER_SMP
bool
diff --git a/include/configs/ph1_ld4.h b/include/configs/ph1_ld4.h
deleted file mode 100644
index a3e4f96..000
--- a/include/configs/ph1_ld4.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (C) 2012-2014 Panasonic Corporation
- * Author: Masahiro Yamada yamad...@jp.panasonic.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __PH1_XXX_H
-#define __PH1_XXX_H
-
-/*
- * Serial Configuration
- * SoC UART : enable CONFIG_UNIPHIER_SERIAL
- * On-board UART: enable CONFIG_SYS_NS16550_SERIAL
- */
-#if 0
-#define CONFIG_SYS_NS16550_SERIAL
-#endif
-
-#define CONFIG_SMC911X
-
-#define CONFIG_DDR_NUM_CH0 1
-#define CONFIG_DDR_NUM_CH1 1
-
-/*
- * Memory Size Mapping
- */
-/* Physical start address of SDRAM */
-#define CONFIG_SDRAM0_BASE 0x8000
-#define CONFIG_SDRAM0_SIZE 0x1000
-#define CONFIG_SDRAM1_BASE 0x9000
-#define CONFIG_SDRAM1_SIZE 0x1000
-
-#define CONFIG_SPL_TEXT_BASE 0x4
-
-#include uniphier-common.h
-
-#endif /* __PH1_XXX_H */
diff --git a/include/configs/ph1_pro4.h b/include/configs/ph1_pro4.h
deleted file mode 100644
index 15849ba..000
--- a/include/configs/ph1_pro4.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (C) 2012-2014 Panasonic Corporation
- * Author: Masahiro Yamada yamad...@jp.panasonic.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __PH1_XXX_H
-#define __PH1_XXX_H
-
-/*
- * Serial Configuration
- * SoC UART : enable CONFIG_UNIPHIER_SERIAL
- * On-board UART: enable CONFIG_SYS_NS16550_SERIAL
- */
-#if 0
-#define CONFIG_SYS_NS16550_SERIAL
-#endif
-
-#define CONFIG_SMC911X
-
-#define CONFIG_DDR_NUM_CH0 2
-#define CONFIG_DDR_NUM_CH1 2
-
-/*
- * Memory Size Mapping
- */
-/* Physical start address of SDRAM */
-#define CONFIG_SDRAM0_BASE 0x8000
-#define CONFIG_SDRAM0_SIZE 0x2000
-#define CONFIG_SDRAM1_BASE 0xa000
-#define CONFIG_SDRAM1_SIZE 0x2000
-
-#define CONFIG_SPL_TEXT_BASE 0x10
-
-#include uniphier-common.h
-
-#endif /* __PH1_XXX_H */
diff --git a/include/configs/ph1_sld8.h b/include/configs/ph1_sld8.h
deleted file mode 100644
index e64d902..000
--- a/include/configs/ph1_sld8.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright (C) 2012-2014 Panasonic Corporation
- * Author: Masahiro Yamada yamad...@jp.panasonic.com
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#ifndef __PH1_XXX_H
-#define __PH1_XXX_H
-
-/*
- * Serial Configuration
- * SoC UART : enable CONFIG_UNIPHIER_SERIAL
- * On-board UART: enable CONFIG_SYS_NS16550_SERIAL
- */
-#if 0
-#define CONFIG_SYS_NS16550_SERIAL
-#endif
-
-#define CONFIG_SMC911X
-
-#define CONFIG_DDR_NUM_CH0 1
-#define CONFIG_DDR_NUM_CH1 1
-
-/* #define CONFIG_DDR_STANDARD */
-
-/*
- * Memory Size Mapping
- */
-/* Physical start address of SDRAM */
-#define CONFIG_SDRAM0_BASE 0x8000
-#define CONFIG_SDRAM0_SIZE 0x1000
-#define CONFIG_SDRAM1_BASE 0x9000
-#define CONFIG_SDRAM1_SIZE 0x1000
-
-#define CONFIG_SPL_TEXT_BASE 0x4
-
-#include uniphier-common.h
-
-#endif /* __PH1_XXX_H */
diff --git a/include/configs/uniphier-common.h b/include/configs/uniphier.h
similarity index 86%
rename from include/configs/uniphier-common.h
rename to include/configs/uniphier.h
index 224c335..733e6fa 100644
--- a/include/configs/uniphier-common.h
+++ b/include/configs/uniphier.h
@@ -10,6 +10,39 @@
#ifndef __CONFIG_UNIPHIER_COMMON_H__
#define __CONFIG_UNIPHIER_COMMON_H__
+#if defined(CONFIG_MACH_PH1_PRO4)
+#define CONFIG_DDR_NUM_CH0 2
+#define CONFIG_DDR_NUM_CH1 2
+
+/* Physical start address of SDRAM */
+#define CONFIG_SDRAM0_BASE 0x8000
+#define
[U-Boot] [PATCH 7/9] ARM: UniPhier: add device tree sources for PH1-sLD3
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/uniphier-ph1-sld3-ref.dts | 57
arch/arm/dts/uniphier-ph1-sld3.dtsi| 121 +
3 files changed, 179 insertions(+)
create mode 100644 arch/arm/dts/uniphier-ph1-sld3-ref.dts
create mode 100644 arch/arm/dts/uniphier-ph1-sld3.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 01df9a9..187d58c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra124-jetson-tk1.dtb \
tegra124-venice2.dtb
dtb-$(CONFIG_ARCH_UNIPHIER) += \
+ uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-ld4-ref.dtb \
uniphier-ph1-sld8-ref.dtb
diff --git a/arch/arm/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/dts/uniphier-ph1-sld3-ref.dts
new file mode 100644
index 000..cb255d2
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-sld3-ref.dts
@@ -0,0 +1,57 @@
+/*
+ * Device Tree Source for UniPhier PH1-sLD3 Reference Board
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ uniphier-ph1-sld3.dtsi
+
+/ {
+ model = Panasonic UniPhier PH1-sLD3 Reference Board;
+ compatible = panasonic,ph1-sld3-ref, panasonic,ph1-sld3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x4000;
+ };
+
+ chosen {
+ bootargs = console=ttyPS0,115200 earlyprintk;
+ stdout-path = uart0;
+ };
+
+ aliases {
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
+};
+
+uart0 {
+ status = okay;
+};
+
+uart1 {
+ status = okay;
+};
+
+i2c0 {
+ status = okay;
+ eeprom {
+ compatible = i2c-eeprom;
+ reg = 0x50;
+ };
+};
+
+usb0 {
+ status = okay;
+};
+
+usb1 {
+ status = okay;
+};
diff --git a/arch/arm/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/dts/uniphier-ph1-sld3.dtsi
new file mode 100644
index 000..23b6767
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-sld3.dtsi
@@ -0,0 +1,121 @@
+/*
+ * Device Tree Source for UniPhier PH1-sLD3 SoC
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = panasonic,ph1-sld3;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a9;
+ reg = 1;
+ };
+ };
+
+ soc {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart0: serial@54006800 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006800 0x20;
+ clock-frequency = 36864000;
+ };
+
+ uart1: serial@54006900 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006900 0x20;
+ clock-frequency = 36864000;
+ };
+
+ uart2: serial@54006a00 {
+ compatible = panasonic,uniphier-uart;
+ status = disabled;
+ reg = 0x54006a00 0x20;
+ clock-frequency = 36864000;
+ };
+
+ i2c0: i2c@5840 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5840 0x40;
+ status = disabled;
+ };
+
+ i2c1: i2c@5848 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5848 0x40;
+ status = disabled;
+ };
+
+ i2c2: i2c@5850 {
+ compatible = panasonic,uniphier-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x5850 0x40;
+ status = disabled;
+ };
+
+ i2c3: i2c@5858 {
+ compatible =
[U-Boot] [PATCH 9/9] ARM: UniPhier: detect the number of flash banks at run-time
Some UniPhier boards are equipped with an expansion slot that
some optional SRAM/NOR-flash cards can be attached to. So, run-time
detection of the number of flash banks would be more user-friendly.
Until this commit, UniPhier boards have achieved this by (ab)using
board_flash_wp_on() because the boot failed if flash_size got zero.
This problem was solved by the previous commit.
Now it is possible to throw away such a tricky workaround.
This commit enables CONFIG_SYS_MAX_FLASH_BANKS_DETECT and refactors
NOR-flash detection code.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/armv7/uniphier/Makefile | 1 +
arch/arm/cpu/armv7/uniphier/board_early_init_r.c | 15 +++
arch/arm/cpu/armv7/uniphier/support_card.c | 125 +++
arch/arm/include/asm/arch-uniphier/board.h | 7 ++
include/configs/uniphier.h | 13 +--
5 files changed, 110 insertions(+), 51 deletions(-)
create mode 100644 arch/arm/cpu/armv7/uniphier/board_early_init_r.c
diff --git a/arch/arm/cpu/armv7/uniphier/Makefile
b/arch/arm/cpu/armv7/uniphier/Makefile
index 0f64d25..4a7b8a9 100644
--- a/arch/arm/cpu/armv7/uniphier/Makefile
+++ b/arch/arm/cpu/armv7/uniphier/Makefile
@@ -11,6 +11,7 @@ obj-y += cache_uniphier.o
obj-$(CONFIG_BOARD_POSTCLK_INIT) += board_postclk_init.o
obj-y += dram_init.o
obj-$(CONFIG_DISPLAY_CPUINFO) += cpu_info.o
+obj-$(CONFIG_BOARD_EARLY_INIT_R) += board_early_init_r.o
obj-$(CONFIG_BOARD_LATE_INIT) += board_late_init.o
obj-$(CONFIG_UNIPHIER_SMP) += smp.o
obj-$(CONFIG_CMD_PINMON) += cmd_pinmon.o
diff --git a/arch/arm/cpu/armv7/uniphier/board_early_init_r.c
b/arch/arm/cpu/armv7/uniphier/board_early_init_r.c
new file mode 100644
index 000..cb7e04f
--- /dev/null
+++ b/arch/arm/cpu/armv7/uniphier/board_early_init_r.c
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2014 Panasonic Corporation
+ * Author: Masahiro Yamada yamad...@jp.panasonic.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/board.h
+
+int board_early_init_r(void)
+{
+ uniphier_board_late_init();
+ return 0;
+}
diff --git a/arch/arm/cpu/armv7/uniphier/support_card.c
b/arch/arm/cpu/armv7/uniphier/support_card.c
index 40d4940..419012e 100644
--- a/arch/arm/cpu/armv7/uniphier/support_card.c
+++ b/arch/arm/cpu/armv7/uniphier/support_card.c
@@ -83,6 +83,12 @@ static int support_card_show_revision(void)
}
#endif
+int check_support_card(void)
+{
+ printf(SC:Micro Support Card );
+ return support_card_show_revision();
+}
+
void support_card_init(void)
{
/*
@@ -94,12 +100,6 @@ void support_card_init(void)
support_card_reset_deassert();
}
-int check_support_card(void)
-{
- printf(SC:Micro Support Card );
- return support_card_show_revision();
-}
-
#if defined(CONFIG_SMC911X)
#include netdev.h
@@ -112,18 +112,14 @@ int board_eth_init(bd_t *bis)
#if !defined(CONFIG_SYS_NO_FLASH)
#include mtd/cfi_flash.h
+#include asm/arch/sbc-regs.h
-#if CONFIG_SYS_MAX_FLASH_BANKS 1
-static phys_addr_t flash_banks_list[CONFIG_SYS_MAX_FLASH_BANKS] =
- CONFIG_SYS_FLASH_BANKS_LIST;
+struct memory_bank {
+ phys_addr_t base;
+ unsigned long size;
+};
-phys_addr_t cfi_flash_bank_addr(int i)
-{
- return flash_banks_list[i];
-}
-#endif
-
-int mem_is_flash(phys_addr_t base)
+static int mem_is_flash(const struct memory_bank *mem)
{
const int loop = 128;
u32 *scratch_addr;
@@ -131,8 +127,9 @@ int mem_is_flash(phys_addr_t base)
int ret = 1;
int i;
- scratch_addr = map_physmem(base + 0x01e0,
- sizeof(u32) * loop, MAP_NOCACHE);
+ /* just in case, use the tail of the memory bank */
+ scratch_addr = map_physmem(mem-base + mem-size - sizeof(u32) * loop,
+ sizeof(u32) * loop, MAP_NOCACHE);
for (i = 0; i loop; i++, scratch_addr++) {
saved_value = readl(scratch_addr);
@@ -150,31 +147,79 @@ int mem_is_flash(phys_addr_t base)
return ret;
}
-int board_flash_wp_on(void)
+#if defined(CONFIG_PFC_MICRO_SUPPORT_CARD)
+ /* {address, size} */
+static const struct memory_bank memory_banks_boot_swap_off[] = {
+ {0x0200, 0x01f0},
+};
+
+static const struct memory_bank memory_banks_boot_swap_on[] = {
+ {0x, 0x01f0},
+};
+#endif
+
+#if defined(CONFIG_DCC_MICRO_SUPPORT_CARD)
+static const struct memory_bank memory_banks_boot_swap_off[] = {
+ {0x0400, 0x0400},
+};
+
+static const struct memory_bank memory_banks_boot_swap_on[] = {
+ {0x, 0x0400},
+ {0x0400, 0x0400},
+};
+#endif
+
+static const struct memory_bank
+*flash_banks_list[CONFIG_SYS_MAX_FLASH_BANKS_DETECT];
+
+phys_addr_t cfi_flash_bank_addr(int i)
{
- int i;
- int ret = 1;
+ return flash_banks_list[i]-base;
+}
- for (i
[U-Boot] [PATCH 2/9] ARM: UniPhier: use boot_is_swapped() macro for readability
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c
index f113db5..3c82a1a 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c
@@ -22,16 +22,7 @@ void sbc_init(void)
writel(SBCTRL2_SAVEPIN_PERI_VALUE, SBCTRL12);
writel(SBCTRL4_SAVEPIN_PERI_VALUE, SBCTRL14);
- if (readl(SBBASE0) 0x1) {
- /*
-* Boot Swap Off: boot from mask ROM
-* 0x-0x01ff: mask ROM
-* 0x0200-0x3eff: memory bank (31MB)
-* 0x03f0-0x3fff: peripherals (1MB)
-*/
- writel(0xbe01, SBBASE0); /* dummy */
- writel(0x0200be01, SBBASE1);
- } else {
+ if (boot_is_swapped()) {
/*
* Boot Swap On: boot from external NOR/SRAM
* 0x0200-0x03ff is a mirror of 0x-0x01ff.
@@ -40,6 +31,15 @@ void sbc_init(void)
* 0x01f0-0x01ff, 0x03f0-0x03ff: peripherals
*/
writel(0xbc01, SBBASE0);
+ } else {
+ /*
+* Boot Swap Off: boot from mask ROM
+* 0x-0x01ff: mask ROM
+* 0x0200-0x3eff: memory bank (31MB)
+* 0x03f0-0x3fff: peripherals (1MB)
+*/
+ writel(0xbe01, SBBASE0); /* dummy */
+ writel(0x0200be01, SBBASE1);
}
#elif defined(CONFIG_DCC_MICRO_SUPPORT_CARD)
#if !defined(CONFIG_SPL_BUILD)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/9] ARM: UniPhier: a collection of nice cleanups of board/SoC support code
Masahiro Yamada (9):
ARM: UniPhier: disable autostart by default
ARM: UniPhier: use boot_is_swapped() macro for readability
ARM: UniPhier: move CONFIG_UNIPHIER_SMP to Kconfig
ARM: UniPhier: move support card select to Kconfig
ARM: UniPhier: merge UniPhier config headers into a single file
ARM: UniPhier: add more device nodes to device tree
ARM: UniPhier: add device tree sources for PH1-sLD3
ARM: UniPhier: extend register area of init page table for PH1-sLD3
ARM: UniPhier: detect the number of flash banks at run-time
arch/arm/cpu/armv7/uniphier/Kconfig | 31 +-
arch/arm/cpu/armv7/uniphier/Makefile | 1 +
arch/arm/cpu/armv7/uniphier/board_early_init_r.c | 15 +++
arch/arm/cpu/armv7/uniphier/init_page_table.c | 7 +-
arch/arm/cpu/armv7/uniphier/ph1-pro4/sbc_init.c | 20 ++--
arch/arm/cpu/armv7/uniphier/support_card.c| 125 +++---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/uniphier-ph1-ld4-ref.dts | 23 +++-
arch/arm/dts/uniphier-ph1-ld4.dtsi| 40 ++-
arch/arm/dts/uniphier-ph1-pro4-ref.dts| 26 -
arch/arm/dts/uniphier-ph1-pro4.dtsi | 64 ++-
arch/arm/dts/uniphier-ph1-sld3-ref.dts| 57 ++
arch/arm/dts/uniphier-ph1-sld3.dtsi | 121 +
arch/arm/dts/uniphier-ph1-sld8-ref.dts| 23 +++-
arch/arm/dts/uniphier-ph1-sld8.dtsi | 40 ++-
arch/arm/include/asm/arch-uniphier/board.h| 7 ++
configs/ph1_ld4_defconfig | 1 +
configs/ph1_pro4_defconfig| 1 +
configs/ph1_sld8_defconfig| 1 +
include/configs/ph1_ld4.h | 53 -
include/configs/ph1_pro4.h| 55 --
include/configs/ph1_sld8.h| 55 --
include/configs/{uniphier-common.h = uniphier.h} | 63 ---
23 files changed, 582 insertions(+), 248 deletions(-)
create mode 100644 arch/arm/cpu/armv7/uniphier/board_early_init_r.c
create mode 100644 arch/arm/dts/uniphier-ph1-sld3-ref.dts
create mode 100644 arch/arm/dts/uniphier-ph1-sld3.dtsi
delete mode 100644 include/configs/ph1_ld4.h
delete mode 100644 include/configs/ph1_pro4.h
delete mode 100644 include/configs/ph1_sld8.h
rename include/configs/{uniphier-common.h = uniphier.h} (84%)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] ARM: UniPhier: move CONFIG_UNIPHIER_SMP to Kconfig
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- arch/arm/cpu/armv7/uniphier/Kconfig | 4 include/configs/ph1_pro4.h | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/uniphier/Kconfig b/arch/arm/cpu/armv7/uniphier/Kconfig index 36b7f11..31a03d9 100644 --- a/arch/arm/cpu/armv7/uniphier/Kconfig +++ b/arch/arm/cpu/armv7/uniphier/Kconfig @@ -9,11 +9,15 @@ config SYS_CONFIG_NAME default ph1_ld4 if MACH_PH1_LD4 default ph1_sld8 if MACH_PH1_SLD8 +config UNIPHIER_SMP + bool + choice prompt UniPhier SoC select config MACH_PH1_PRO4 bool PH1-Pro4 + select UNIPHIER_SMP config MACH_PH1_LD4 bool PH1-LD4 diff --git a/include/configs/ph1_pro4.h b/include/configs/ph1_pro4.h index fc5132d..7780030 100644 --- a/include/configs/ph1_pro4.h +++ b/include/configs/ph1_pro4.h @@ -37,8 +37,6 @@ #define CONFIG_DDR_NUM_CH0 2 #define CONFIG_DDR_NUM_CH1 2 -#define CONFIG_UNIPHIER_SMP - /* * Memory Size Mapping */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/25] x86: ich6-gpio: Add Intel Tunnel Creek GPIO support
Hi Bin,
On 5 December 2014 at 01:35, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Dec 5, 2014 at 6:43 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:01, Bin Meng bmeng...@gmail.com wrote:
Intel Tunnel Creek GPIO register block is compatible with current
ich6-gpio driver, except the offset and content of GPIO block base
address register in the LPC PCI configuration space are different.
Use u16 instead of u32 to store the 16-bit I/O address of the GPIO
registers so that it could support both Ivybridge and Tunnel Creek.
How does that help?
The Tunnel Creek GPIO base address register bit31 is bit to control
the I/O decode of the GPIO block (1 means decode enable), while on the
Ivybridge bit31-bit16 is reserved (read returns 0).
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/include/asm/arch-queensbay/gpio.h | 13 +
arch/x86/include/asm/gpio.h| 2 +-
board/google/chromebook_link/link.c| 2 +-
drivers/gpio/intel_ich6_gpio.c | 17 -
4 files changed, 23 insertions(+), 11 deletions(-)
create mode 100644 arch/x86/include/asm/arch-queensbay/gpio.h
diff --git a/arch/x86/include/asm/arch-queensbay/gpio.h
b/arch/x86/include/asm/arch-queensbay/gpio.h
new file mode 100644
index 000..ab4e059
--- /dev/null
+++ b/arch/x86/include/asm/arch-queensbay/gpio.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _X86_ARCH_GPIO_H_
+#define _X86_ARCH_GPIO_H_
+
+/* Where in config space is the register that points to the GPIO
registers? */
+#define PCI_CFG_GPIOBASE 0x44
+
+#endif /* _X86_ARCH_GPIO_H_ */
diff --git a/arch/x86/include/asm/gpio.h b/arch/x86/include/asm/gpio.h
index 5540d42..83878a7 100644
--- a/arch/x86/include/asm/gpio.h
+++ b/arch/x86/include/asm/gpio.h
@@ -11,7 +11,7 @@
#include asm-generic/gpio.h
struct ich6_bank_platdata {
- uint32_t base_addr;
+ uint16_t base_addr;
const char *bank_name;
};
diff --git a/board/google/chromebook_link/link.c
b/board/google/chromebook_link/link.c
index 4d95c1c..9978e92 100644
--- a/board/google/chromebook_link/link.c
+++ b/board/google/chromebook_link/link.c
@@ -125,7 +125,7 @@ int board_early_init_f(void)
return 0;
}
-void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
+void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
{
/* GPIO Set 1 */
if (gpio-set1.level)
diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index 3a2e1b0..3b2962a 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -39,12 +39,12 @@
struct ich6_bank_priv {
/* These are I/O addresses */
- uint32_t use_sel;
- uint32_t io_sel;
- uint32_t lvl;
+ uint16_t use_sel;
+ uint16_t io_sel;
+ uint16_t lvl;
};
-__weak void setup_pch_gpios(u32 gpiobase, const struct pch_gpio_map *gpio)
+__weak void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio)
{
return;
}
@@ -62,7 +62,7 @@ static int gpio_ich6_ofdata_to_platdata(struct udevice
*dev)
u8 tmpbyte;
u16 tmpword;
u32 tmplong;
- u32 gpiobase;
+ u16 gpiobase;
int offset;
/* Where should it be? */
@@ -121,11 +121,10 @@ static int gpio_ich6_ofdata_to_platdata(struct
udevice *dev)
/*
* GPIOBASE moved to its current offset with ICH6, but prior to
* that it was unused (or undocumented). Check that it looks
-* okay: not all ones or zeros, and mapped to I/O space (bit 0).
+* okay: not all ones or zeros.
*/
tmplong = pci_read_config32(pci_dev, PCI_CFG_GPIOBASE);
- if (tmplong == 0x || tmplong == 0x ||
- !(tmplong 0x0001)) {
Why take out this check?
Again the Tunnel Creek GPIO base address register bit0 is reserved
(read returns 0), while on the Ivybridge the bit0 is used to indicate
it is an I/O space.
OK can you add a comment here about that?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/25] x86: Integrate Tunnel Creek processor microcode
Hi Bin, On 5 December 2014 at 02:14, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Fri, Dec 5, 2014 at 7:43 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote: Integrate the processor microcode version 1.05 for Tunnel Creek, CPUID device 20661h. Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/queensbay/M0220661105.inc | 1288 1 file changed, 1288 insertions(+) create mode 100644 arch/x86/cpu/queensbay/M0220661105.inc Can we put this into the device tree? Unfortunately the microcode is required by the call to TempRamInit in FSP in car_init, where the device tree functionality is not available. We can of course duplicate one in device tree for reference, not sure if it is necessary. OK I was hoping you weren't going to say that. There is not even a stack at this stage so device tree is out of the question. I wonder how common this is. Is there any way to provide a 'NULL' microcode update and then do it later? This is some of the pain of dealing with binary blobs. Let's see where this lands but we may want to change things around in start.S to provide for this more nicely. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/25] x86: Add basic support to queensbay platform and crownbay board
Hi Bin,
On 5 December 2014 at 02:40, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Dec 5, 2014 at 7:48 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:02, Bin Meng bmeng...@gmail.com wrote:
Implement minimum required functions for the basic support to
queensbay platform and crownbay board.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
arch/x86/cpu/queensbay/Makefile | 9 +
arch/x86/cpu/queensbay/tnc.c | 48 +++
arch/x86/cpu/queensbay/tnc_car.S | 75
arch/x86/cpu/queensbay/tnc_dram.c | 81
+++
arch/x86/cpu/queensbay/tnc_pci.c | 62 ++
board/intel/crownbay/MAINTAINERS | 6 +++
board/intel/crownbay/Makefile | 7
board/intel/crownbay/crownbay.c | 20 ++
board/intel/crownbay/start.S | 9 +
9 files changed, 317 insertions(+)
create mode 100644 arch/x86/cpu/queensbay/Makefile
create mode 100644 arch/x86/cpu/queensbay/tnc.c
create mode 100644 arch/x86/cpu/queensbay/tnc_car.S
create mode 100644 arch/x86/cpu/queensbay/tnc_dram.c
create mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
create mode 100644 board/intel/crownbay/MAINTAINERS
create mode 100644 board/intel/crownbay/Makefile
create mode 100644 board/intel/crownbay/crownbay.c
create mode 100644 board/intel/crownbay/start.S
diff --git a/arch/x86/cpu/queensbay/Makefile
b/arch/x86/cpu/queensbay/Makefile
new file mode 100644
index 000..ace04ca
--- /dev/null
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += tnc_car.o tnc_dram.o tnc.o
+obj-y += fsp_configs.o fsp_support.o
+obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
new file mode 100644
index 000..c0d19aa
--- /dev/null
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/io.h
+#include asm/post.h
+#include asm/arch/fsp/fsp_support.h
+
+int arch_cpu_init(void)
+{
+ post_code(POST_CPU_INIT);
+#ifdef CONFIG_SYS_X86_TSC_TIMER
+ timer_set_base(rdtsc());
+#endif
+
+ return x86_cpu_init_f();
+}
+
+int print_cpuinfo(void)
+{
+ post_code(POST_CPU_INFO);
+ return default_print_cpuinfo();
+}
+
+void reset_cpu(ulong addr)
+{
+ /* cold reset */
+ outb(0x06, 0xcf9);
I think there is a constant somewhere for cf9?
Yes, I found one in arch/x86/include/asm/processor.h and will use that.
+}
+
+void board_final_cleanup(void)
+{
+ EFI_STATUS status;
+
+ /* call into FspNotify */
Remove blank line
OK.
+
+ debug(Calling into FSP (notify phase EnumInitPhaseReadyToBoot): );
+ status = FspNotifyWrapper(NULL, EnumInitPhaseReadyToBoot);
Are we stuck with these mixed case identifiers?
I may have to fix FSP support library coding style issues in v2.
+ if (status != FSP_SUCCESS)
+ debug(fail, error code %x\n, status);
+ else
+ debug(OK\n);
+
+ return;
+}
diff --git a/arch/x86/cpu/queensbay/tnc_car.S
b/arch/x86/cpu/queensbay/tnc_car.S
new file mode 100644
index 000..722de7f
--- /dev/null
+++ b/arch/x86/cpu/queensbay/tnc_car.S
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2014, Bin Meng bmeng...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include asm/post.h
+
+.globl car_init
+car_init:
+ /*
+* Note: ebp holds the BIST value (built-in self test) so far, but
ebp
+* will be destroyed through the FSP call, thus we have to test the
+* BIST value here before we call into FSP.
+*/
+ test%ebp, %ebp
+ jz car_init_start
+ post_code(POST_BIST_FAILURE)
+ jmp die
Is there no way to save it anywhere?
Unfortunately I did not find a way to save the ebp through the FSP
call so far. The FSP documentation mentions that FSP tries to save
bootloader's stack before call to FspInit to a temporary memory block
after the call, however I found it is not working as documented. I may
look into this in the future, but for now I think we have to let it
be.
Not great, but score 1 for the binary blobs.
+
+car_init_start:
+ post_code(POST_CAR_START)
+ lea find_fsp_header_stack, %esp
+ jmp FindFspHeader
+
+find_fsp_header_ret:
+ /* EAX points to FSP_INFO_HEADER */
+ mov %eax, %ebp
+
+ /* sanity test */
+ cmp $CONFIG_FSP_LOCATION, %eax
+ jb die
+
+ /* calculate TempRamInitEntry address */
+ mov 0x30(%ebp), %eax
+ add 0x1c(%ebp), %eax
+
+ /* call FSP
[U-Boot] [PATCH v5 0/11] dm: Add I2C support and convert sandbox, tegra
This series adds I2C support to driver model. It has become apparent that this is a high priority as it is widely used. It follows along to some extent from the SPI conversion. Several changes are made from the original I2C implementations. Firstly it is not necessary to specify the chip address with every call, since each chip knows its own address - it is stored in struct dm_i2c_chip which is attached to each chip on the I2C bus. However, this information *is* passed to the driver since I presume most drivers need it and it would be cumbersome to look up in every call. Secondly there is no concept of a 'current' I2C bus so all associated logic is removed. With driver model i2c_set_bus_num() and i2c_get_bus_num() are not available. Since the chip device specifies both the bus and the chip address, there is no need for this concept. It also causes problems when one driver changes the current bus and forgets to change it back. Thirdly initialisation is handled by driver model's normal probe() method on each device so there should be no need for i2c_init_all(), i2c_init(), i2c_init_board(), i2c_board_late_init() and board_i2c_init(). I2C muxes are not yet supported. To support these we will need to maintain state of the current mux settings to avoid resetting every mux every time. Probably we need to add a sandbox I2C mux driver to permit testing of this. This can probably be done later. Platform data is not yet supported either, only device tree. The U_BOOT_I2C_MKENT_COMPLETE() and U_BOOT_I2C_ADAP_COMPLETE() macros are not used. Also struct i2c_adapter is not defined anymore. This will need to be addressed, perhaps as part of converting over a board that does not use device tree, assuming that we want to support this. The following I2C CONFIGs are no-longer needed when driver model is used: CONFIG_SYS_I2C_INIT_BOARD - each I2C bus is inited in its probe() method CONFIG_I2C_MULTI_BUS - we always support multi-bus with driver model CONFIG_SYS_MAX_I2C_BUS- the device tree aliases define available buses CONFIG_SYS_I2C_SPEED - the device tree specifies the speed for each bus CONFIG_SYS_I2C- this is the 'new old' API, now deprecated There are a few SPI patches included here due to a dependency on a new device binding function. v3 changes the uclass to driver interface significantly. It is now a list of messages to be processed by the driver. This matches the Linux user space API which may be a benefit. It does introduce one complication, which is that the protocol does not support separate chip offset and data. I have enhanced it to do so. This series is available at u-boot-dm/i2c-working2. Changes in v5: - Add a function comment for i2c_probe_chip() - Add an assert for offset_len in i2c_setup_offset() - Add more detail to return value comment on get_buf_speed() - Add more detail to return value comment on xfer() method - Adjust tests for DM_I2C_CHIP_RE_ADDRESS split - Fix -INVAL typo - Make i2c_get_bus_speed() independent of i2c_set_bus_speed() - Split DM_I2C_CHIP_RD_ADDRESS into read and write varaints - Update comments in struct i2c_msg to allow buf to be NULL - Use a NULL buffer in i2c_probe_chip() Changes in v4: - Add a constant for I2C_MAX_OFFSET_LEN - Add a probe_chip() method for the eeprom - Add a probe_chip() method to the uclass - Add a remove() method for the eeprom - Add an assert for non-null - Add an eeprom test mode - Add chip flags to i2c_probe() - Add comment to i2c_setup_offset() - Add comments to indicate which methods are optional - Add comments to set_bus_speed() method - Add eeprom debugging output - Add new patch to add newline to debug() messages - Add probe_chip() method - Add support for eeprom offset length - Add tests for offset length - Adjust i2c_bind_driver() to avoid calloc()/free() - Adjust tests to match uclass changes - Drop set_offset_len() method - Fix copying of chip flags to message in i2c_setup_offset() - Fix endianness of i2c_setup_offset() - Fix method comment for xfer() - Invert return value of i2c_setup_offset() - Probe with a message length of 0 - Rename i2c_generic_drv to i2c_generic_chip_drv - Rename i2c_read_bytewise() and implement a real one - Update call to i2c_probe() Changes in v3: - Add a helper to query chip flags - Add new 'i2c flags' command to get/set chip flags - Add support for reading a byte at a time with an address for each byte - Adjust for slightly altered I2C uclass API - Change driver to support new message-based I2C uclass API - Change uclass = driver API to use a message list - Correct bogus address len code (was confused with chip address length) - Drop extra call to i2c_bind_driver() in i2c_probe() - Update emulator for new uclass interface - Update for new uclass = driver interface - Update for new uclass = emulateor interface Changes in v2: - Add a 'deblock' method to recover an I2C bus stuck in mid-transaction - Add a helper function to find a chip on a particular bus number - Add a new
[U-Boot] [PATCH v5 03/11] dm: i2c: Add I2C emulation driver for sandbox
In order to test I2C we need some sort of emulation interface. Add hooks
to allow a driver to emulate an I2C device for sandbox.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-emul-uclass.c | 14 ++
include/dm/uclass-id.h| 1 +
3 files changed, 16 insertions(+)
create mode 100644 drivers/i2c/i2c-emul-uclass.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 063e097..5a93473 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
obj-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
obj-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
obj-$(CONFIG_SYS_I2C_S3C24X0) += s3c24x0_i2c.o
+obj-$(CONFIG_SYS_I2C_SANDBOX) += i2c-emul-uclass.o
obj-$(CONFIG_SYS_I2C_SH) += sh_i2c.o
obj-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
diff --git a/drivers/i2c/i2c-emul-uclass.c b/drivers/i2c/i2c-emul-uclass.c
new file mode 100644
index 000..aa89f95
--- /dev/null
+++ b/drivers/i2c/i2c-emul-uclass.c
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include i2c.h
+
+UCLASS_DRIVER(i2c_emul) = {
+ .id = UCLASS_I2C_EMUL,
+ .name = i2c_emul,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 01866c3..16e4224 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -19,6 +19,7 @@ enum uclass_id {
UCLASS_TEST_FDT,
UCLASS_TEST_BUS,
UCLASS_SPI_EMUL,/* sandbox SPI device emulator */
+ UCLASS_I2C_EMUL,/* sandbox I2C device emulator */
UCLASS_SIMPLE_BUS,
/* U-Boot uclasses start here */
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] arm: exynos: add display clocks for Exynos5800
Dear Ajay Kumar,
On 5 December 2014 at 23:13, Ajay Kumar ajaykumar...@samsung.com wrote:
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5800 needed by
exynos video driver.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/cpu/armv7/exynos/clock.c | 63
+++-
arch/arm/include/asm/arch-exynos/clk.h |3 ++
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 8fab135..1a34ad6 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -1066,6 +1066,36 @@ static unsigned long exynos5420_get_lcd_clk(void)
return pclk;
}
+static unsigned long exynos5800_get_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned long sclk;
+ unsigned sel;
just unsigned? why don't you specify in detail?
+ unsigned ratio;
+
+ sel = (readl(clk-src_disp10) 4) 7;
please add comment how you get sel from disp10.
and if 7 means mask then please use 0x7. it looks more clearly.
+
+ /*
+* Mapping of CLK_SRC_DISP10 CLKMUX_FIMD1 [6:4] values into
+* PLLs. The first element is a placeholder to bypass the
+* default settig.
+*/
+ const int reg_map[] = {0, CPLL, DPLL, MPLL, SPLL,
+ IPLL, EPLL, RPLL};
please don't define local variable at middle of function.
you can move it to top of the function or
it seems to use sel is true then you can move it into the if statement.
+ if (sel)
+ sclk = get_pll_clk(reg_map[sel]);
+ else
+ sclk = 2400;
please define this value.
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ ratio = readl(clk-div_disp10) 0xf;
+
+ return sclk / (ratio + 1);
+}
+
void exynos4_set_lcd_clk(void)
{
struct exynos4_clock *clk =
@@ -1197,6 +1227,31 @@ void exynos5420_set_lcd_clk(void)
writel(cfg, clk-div_disp10);
}
+void exynos5800_set_lcd_clk(void)
+{
+ struct exynos5420_clock *clk =
+ (struct exynos5420_clock *)samsung_get_base_clock();
+ unsigned int cfg;
+
+ /*
+* Use RPLL for pixel clock
+* CLK_SRC_DISP10 CLKMUX_FIMD1 [6:4]
+* ==
+* 111: SCLK_RPLL
+*/
+ cfg = readl(clk-src_disp10) | (7 4);
+ writel(cfg, clk-src_disp10);
+
+ /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+ cfg = readl(clk-div_disp10);
+ cfg = ~(0xf 0);
+ cfg |= (0 0);
it looks meaningless.
+ writel(cfg, clk-div_disp10);
+}
+
void exynos4_set_mipi_clk(void)
{
struct exynos4_clock *clk =
@@ -1669,8 +1724,10 @@ unsigned long get_lcd_clk(void)
if (cpu_is_exynos4())
return exynos4_get_lcd_clk();
else {
- if (proid_is_exynos5420() || proid_is_exynos5800())
+ if (proid_is_exynos5420())
return exynos5420_get_lcd_clk();
+ else if (proid_is_exynos5800())
+ return exynos5800_get_lcd_clk();
else
return exynos5_get_lcd_clk();
}
@@ -1683,8 +1740,10 @@ void set_lcd_clk(void)
else {
if (proid_is_exynos5250())
exynos5_set_lcd_clk();
- else if (proid_is_exynos5420() || proid_is_exynos5800())
+ else if (proid_is_exynos5420())
exynos5420_set_lcd_clk();
+ else
+ exynos5800_set_lcd_clk();
}
}
diff --git a/arch/arm/include/asm/arch-exynos/clk.h
b/arch/arm/include/asm/arch-exynos/clk.h
index db24dc0..bf3d348 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -16,6 +16,9 @@
#define BPLL 5
#define RPLL 6
#define SPLL 7
+#define CPLL 8
+#define DPLL 9
+#define IPLL 10
#define MASK_PRE_RATIO(x) (0xff ((x 4) + 8))
#define MASK_RATIO(x) (0xf (x 4))
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks,
Minkyu Kang.
--
from. prom.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 04/11] dm: i2c: Add a sandbox I2C driver
This driver includes some test features such as only supporting certain
bus speeds. It passes its I2C traffic through to an emulator.
Acked-by: Heiko Schocher h...@denx.de
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4:
- Drop set_offset_len() method
Changes in v3:
- Update for new uclass = driver interface
Changes in v2: None
drivers/i2c/Makefile | 2 +-
drivers/i2c/sandbox_i2c.c | 129 ++
2 files changed, 130 insertions(+), 1 deletion(-)
create mode 100644 drivers/i2c/sandbox_i2c.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 5a93473..6f3c86c 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -27,7 +27,7 @@ obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
obj-$(CONFIG_SYS_I2C_PPC4XX) += ppc4xx_i2c.o
obj-$(CONFIG_SYS_I2C_RCAR) += rcar_i2c.o
obj-$(CONFIG_SYS_I2C_S3C24X0) += s3c24x0_i2c.o
-obj-$(CONFIG_SYS_I2C_SANDBOX) += i2c-emul-uclass.o
+obj-$(CONFIG_SYS_I2C_SANDBOX) += sandbox_i2c.o i2c-emul-uclass.o
obj-$(CONFIG_SYS_I2C_SH) += sh_i2c.o
obj-$(CONFIG_SYS_I2C_SOFT) += soft_i2c.o
obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o
diff --git a/drivers/i2c/sandbox_i2c.c b/drivers/i2c/sandbox_i2c.c
new file mode 100644
index 000..c07308e
--- /dev/null
+++ b/drivers/i2c/sandbox_i2c.c
@@ -0,0 +1,129 @@
+/*
+ * Simulate an I2C port
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include i2c.h
+#include asm/test.h
+#include dm/lists.h
+#include dm/device-internal.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct dm_sandbox_i2c_emul_priv {
+ struct udevice *emul;
+};
+
+static int get_emul(struct udevice *bus, uint chip_addr, struct udevice **devp,
+ struct dm_i2c_ops **opsp)
+{
+ const void *blob = gd-fdt_blob;
+ struct dm_i2c_chip *priv;
+ struct udevice *dev;
+ int ret;
+
+ *devp = NULL;
+ *opsp = NULL;
+ ret = i2c_get_chip(bus, chip_addr, dev);
+ if (ret)
+ return ret;
+ priv = dev_get_parentdata(dev);
+ if (!priv-emul) {
+ int node;
+
+ debug(Scanning i2c bus '%s' for devices\n, dev-name);
+ for (node = fdt_first_subnode(blob, dev-of_offset);
+ node = 0;
+ node = fdt_next_subnode(blob, node)) {
+ int ret;
+
+ ret = lists_bind_fdt(dev, blob, node, priv-emul);
+ if (ret)
+ return ret;
+ debug(Found emul '%s' for i2c device '%s'\n,
+ priv-emul-name, dev-name);
+ break;
+ }
+ }
+
+ if (!priv-emul)
+ return -ENODEV;
+ ret = device_probe(priv-emul);
+ if (ret)
+ return ret;
+ *devp = priv-emul;
+ *opsp = i2c_get_ops(priv-emul);
+
+ return 0;
+}
+
+static int sandbox_i2c_xfer(struct udevice *bus, struct i2c_msg *msg,
+ int nmsgs)
+{
+ struct dm_i2c_bus *i2c = bus-uclass_priv;
+ struct dm_i2c_ops *ops;
+ struct udevice *emul, *dev;
+ bool is_read;
+ int ret;
+
+ /* Special test code to return success but with no emulation */
+ if (msg-addr == SANDBOX_I2C_TEST_ADDR)
+ return 0;
+
+ ret = get_emul(bus, msg-addr, emul, ops);
+ if (ret)
+ return ret;
+
+ /* For testing, require an offset length of 1 */
+ ret = i2c_get_chip(bus, msg-addr, dev);
+ if (ret)
+ return ret;
+
+ /*
+* For testing, don't allow writing above 100KHz for writes and
+* 400KHz for reads
+*/
+ is_read = nmsgs 1;
+ if (i2c-speed_hz (is_read ? 40 : 10))
+ return -EINVAL;
+ return ops-xfer(emul, msg, nmsgs);
+}
+
+static const struct dm_i2c_ops sandbox_i2c_ops = {
+ .xfer = sandbox_i2c_xfer,
+};
+
+static int sandbox_i2c_child_pre_probe(struct udevice *dev)
+{
+ struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
+
+ /* Ignore our test address */
+ if (i2c_chip-chip_addr == SANDBOX_I2C_TEST_ADDR)
+ return 0;
+ if (dev-of_offset == -1)
+ return 0;
+
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
+ i2c_chip);
+}
+
+static const struct udevice_id sandbox_i2c_ids[] = {
+ { .compatible = sandbox,i2c },
+ { }
+};
+
+U_BOOT_DRIVER(i2c_sandbox) = {
+ .name = i2c_sandbox,
+ .id = UCLASS_I2C,
+ .of_match = sandbox_i2c_ids,
+ .per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
+ .child_pre_probe = sandbox_i2c_child_pre_probe,
+ .ops= sandbox_i2c_ops,
+};
--
2.2.0.rc0.207.ga3a616c
[U-Boot] [PATCH v5 08/11] dm: Add a simple EEPROM driver
There seem to be a few EEPROM drivers around - perhaps we should have a
single standard one? This simple driver is used for sandbox testing, but
could be pressed into more active service.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Update commit message for EEPROM driver
drivers/misc/Makefile | 1 +
drivers/misc/i2c_eeprom.c | 51 +++
include/dm/uclass-id.h| 1 +
include/i2c_eeprom.h | 19 ++
4 files changed, 72 insertions(+)
create mode 100644 drivers/misc/i2c_eeprom.c
create mode 100644 include/i2c_eeprom.h
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index ff02184..6fa836f 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_CROS_EC_SANDBOX) += cros_ec_sandbox.o
obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
obj-$(CONFIG_FSL_IIM) += fsl_iim.o
obj-$(CONFIG_GPIO_LED) += gpio_led.o
+obj-$(CONFIG_I2C_EEPROM) += i2c_eeprom.o
obj-$(CONFIG_FSL_MC9SDZ60) += mc9sdz60.o
obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o
obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
new file mode 100644
index 000..d0548ec
--- /dev/null
+++ b/drivers/misc/i2c_eeprom.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include i2c.h
+#include i2c_eeprom.h
+
+static int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf,
+ int size)
+{
+ return -ENODEV;
+}
+
+static int i2c_eeprom_write(struct udevice *dev, int offset,
+ const uint8_t *buf, int size)
+{
+ return -ENODEV;
+}
+
+struct i2c_eeprom_ops i2c_eeprom_std_ops = {
+ .read = i2c_eeprom_read,
+ .write = i2c_eeprom_write,
+};
+
+int i2c_eeprom_std_probe(struct udevice *dev)
+{
+ return 0;
+}
+
+static const struct udevice_id i2c_eeprom_std_ids[] = {
+ { .compatible = i2c-eeprom },
+ { }
+};
+
+U_BOOT_DRIVER(i2c_eeprom_std) = {
+ .name = i2c_eeprom,
+ .id = UCLASS_I2C_EEPROM,
+ .of_match = i2c_eeprom_std_ids,
+ .probe = i2c_eeprom_std_probe,
+ .priv_auto_alloc_size = sizeof(struct i2c_eeprom),
+ .ops= i2c_eeprom_std_ops,
+};
+
+UCLASS_DRIVER(i2c_eeprom) = {
+ .id = UCLASS_I2C_EEPROM,
+ .name = i2c_eeprom,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 16e4224..f17c3c2 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -32,6 +32,7 @@ enum uclass_id {
UCLASS_THERMAL, /* Thermal sensor */
UCLASS_I2C, /* I2C bus */
UCLASS_I2C_GENERIC, /* Generic I2C device */
+ UCLASS_I2C_EEPROM, /* I2C EEPROM device */
UCLASS_COUNT,
UCLASS_INVALID = -1,
diff --git a/include/i2c_eeprom.h b/include/i2c_eeprom.h
new file mode 100644
index 000..ea6c962
--- /dev/null
+++ b/include/i2c_eeprom.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __I2C_EEPROM
+#define __I2C_EEPROM
+
+struct i2c_eeprom_ops {
+ int (*read)(struct udevice *dev, int offset, uint8_t *buf, int size);
+ int (*write)(struct udevice *dev, int offset, const uint8_t *buf,
+int size);
+};
+
+struct i2c_eeprom {
+};
+
+#endif
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 10/11] dm: device: Add newline to debug() messages
Some of these are missing a newline. Add it.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4:
- Add new patch to add newline to debug() messages
Changes in v3: None
Changes in v2: None
drivers/core/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 6793e1c..963b16f 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -234,7 +234,7 @@ int device_probe(struct udevice *dev)
void *dev_get_platdata(struct udevice *dev)
{
if (!dev) {
- dm_warn(%s: null device, __func__);
+ dm_warn(%s: null device\n, __func__);
return NULL;
}
@@ -244,7 +244,7 @@ void *dev_get_platdata(struct udevice *dev)
void *dev_get_priv(struct udevice *dev)
{
if (!dev) {
- dm_warn(%s: null device, __func__);
+ dm_warn(%s: null device\n, __func__);
return NULL;
}
@@ -254,7 +254,7 @@ void *dev_get_priv(struct udevice *dev)
void *dev_get_parentdata(struct udevice *dev)
{
if (!dev) {
- dm_warn(%s: null device, __func__);
+ dm_warn(%s: null device\n, __func__);
return NULL;
}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 02/11] dm: i2c: Implement driver model support in the i2c command
The concept of a 'current bus' is now implemented in the command line
rather than in the uclass. Also the address length does not need to
be specified with each command - really we should consider dropping
this from most commands but it works OK for now.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5: None
Changes in v4:
- Update call to i2c_probe()
Changes in v3:
- Add new 'i2c flags' command to get/set chip flags
- Adjust for slightly altered I2C uclass API
Changes in v2:
- Call the deblock() method for 'i2c reset'
- Change alen to int so that it can be -1 (this was a bug)
common/cmd_i2c.c | 376 +++
1 file changed, 323 insertions(+), 53 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index c266b88..22db1bb 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -69,8 +69,10 @@
#include bootretry.h
#include cli.h
#include command.h
+#include dm.h
#include edid.h
#include environment.h
+#include errno.h
#include i2c.h
#include malloc.h
#include asm/byteorder.h
@@ -117,6 +119,60 @@ static uchar i2c_no_probes[] = CONFIG_SYS_I2C_NOPROBES;
#define DISP_LINE_LEN 16
+/*
+ * Default for driver model is to use the chip's existing address length.
+ * For legacy code, this is not stored, so we need to use a suitable
+ * default.
+ */
+#ifdef CONFIG_DM_I2C
+#define DEFAULT_ADDR_LEN (-1)
+#else
+#define DEFAULT_ADDR_LEN 1
+#endif
+
+#ifdef CONFIG_DM_I2C
+static struct udevice *i2c_cur_bus;
+
+static int i2c_set_bus_num(unsigned int busnum)
+{
+ struct udevice *bus;
+ int ret;
+
+ ret = uclass_get_device_by_seq(UCLASS_I2C, busnum, bus);
+ if (ret) {
+ debug(%s: No bus %d\n, __func__, busnum);
+ return ret;
+ }
+ i2c_cur_bus = bus;
+
+ return 0;
+}
+
+static int i2c_get_cur_bus(struct udevice **busp)
+{
+ if (!i2c_cur_bus) {
+ puts(No I2C bus selected\n);
+ return -ENODEV;
+ }
+ *busp = i2c_cur_bus;
+
+ return 0;
+}
+
+static int i2c_get_cur_bus_chip(uint chip_addr, struct udevice **devp)
+{
+ struct udevice *bus;
+ int ret;
+
+ ret = i2c_get_cur_bus(bus);
+ if (ret)
+ return ret;
+
+ return i2c_get_chip(bus, chip_addr, devp);
+}
+
+#endif
+
/**
* i2c_init_board() - Board-specific I2C bus init
*
@@ -143,7 +199,7 @@ void i2c_init_board(void)
*
* Returns I2C bus speed in Hz.
*/
-#if !defined(CONFIG_SYS_I2C)
+#if !defined(CONFIG_SYS_I2C) !defined(CONFIG_DM_I2C)
/*
* TODO: Implement architecture-specific get/set functions
* Should go away, if we switched completely to new multibus support
@@ -182,12 +238,12 @@ int i2c_set_bus_speed(unsigned int speed)
*
* Returns the address length.
*/
-static uint get_alen(char *arg)
+static uint get_alen(char *arg, int default_len)
{
int j;
int alen;
- alen = 1;
+ alen = default_len;
for (j = 0; j 8; j++) {
if (arg[j] == '.') {
alen = arg[j+1] - '0';
@@ -227,8 +283,13 @@ static int i2c_report_err(int ret, enum i2c_err_op op)
static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
u_char chip;
- uintdevaddr, alen, length;
+ uintdevaddr, length;
+ int alen;
u_char *memaddr;
+ int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+#endif
if (argc != 5)
return CMD_RET_USAGE;
@@ -243,7 +304,7 @@ static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
* 2 bytes long. Some day it might be 3 bytes long :-).
*/
devaddr = simple_strtoul(argv[2], NULL, 16);
- alen = get_alen(argv[2]);
+ alen = get_alen(argv[2], DEFAULT_ADDR_LEN);
if (alen 3)
return CMD_RET_USAGE;
@@ -257,18 +318,31 @@ static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
*/
memaddr = (u_char *)simple_strtoul(argv[4], NULL, 16);
- if (i2c_read(chip, devaddr, alen, memaddr, length) != 0) {
- i2c_report_err(-1, I2C_ERR_READ);
- return 1;
- }
+#ifdef CONFIG_DM_I2C
+ ret = i2c_get_cur_bus_chip(chip, dev);
+ if (!ret alen != -1)
+ ret = i2c_set_chip_offset_len(dev, alen);
+ if (!ret)
+ ret = i2c_read(dev, devaddr, memaddr, length);
+#else
+ ret = i2c_read(chip, devaddr, alen, memaddr, length);
+#endif
+ if (ret)
+ return i2c_report_err(ret, I2C_ERR_READ);
+
return 0;
}
static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int argc, char * const
argv[])
{
u_char chip;
- uintdevaddr, alen, length;
+ uintdevaddr, length;
+ int alen;
u_char *memaddr;
+ int ret;
+#ifdef CONFIG_DM_I2C
+ struct
[U-Boot] [PATCH v5 07/11] dm: i2c: dts: Add an I2C bus for sandbox
Add an I2C bus to the device tree, with an EEPROM emulator attached to one
of the addresses.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/sandbox/dts/sandbox.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 7614715..11748ae 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -134,6 +134,23 @@
num-gpios = 20;
};
+ i2c@0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0;
+ compatible = sandbox,i2c;
+ clock-frequency = 40;
+ eeprom@2c {
+ reg = 0x2c;
+ compatible = i2c-eeprom;
+ emul {
+ compatible = sandbox,i2c-eeprom;
+ sandbox,filename = i2c.bin;
+ sandbox,size = 128;
+ };
+ };
+ };
+
spi@0 {
#address-cells = 1;
#size-cells = 0;
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 01/11] dm: i2c: Add a uclass for I2C
The uclass implements the same operations as the current I2C framework but
makes some changes to make it fit driver model better:
- Remove the chip address from API calls
- Remove the address length from API calls
- Remove concept of 'current' I2C bus
- Drop all existing init functions
Acked-by: Heiko Schocher h...@denx.de
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5:
- Add a function comment for i2c_probe_chip()
- Add an assert for offset_len in i2c_setup_offset()
- Add more detail to return value comment on get_buf_speed()
- Add more detail to return value comment on xfer() method
- Fix -INVAL typo
- Make i2c_get_bus_speed() independent of i2c_set_bus_speed()
- Split DM_I2C_CHIP_RD_ADDRESS into read and write varaints
- Update comments in struct i2c_msg to allow buf to be NULL
- Use a NULL buffer in i2c_probe_chip()
Changes in v4:
- Add a constant for I2C_MAX_OFFSET_LEN
- Add a probe_chip() method to the uclass
- Add chip flags to i2c_probe()
- Add comment to i2c_setup_offset()
- Add comments to indicate which methods are optional
- Add comments to set_bus_speed() method
- Adjust i2c_bind_driver() to avoid calloc()/free()
- Drop set_offset_len() method
- Fix copying of chip flags to message in i2c_setup_offset()
- Fix endianness of i2c_setup_offset()
- Fix method comment for xfer()
- Invert return value of i2c_setup_offset()
- Probe with a message length of 0
- Rename i2c_generic_drv to i2c_generic_chip_drv
- Rename i2c_read_bytewise() and implement a real one
Changes in v3:
- Add a helper to query chip flags
- Add support for reading a byte at a time with an address for each byte
- Change uclass = driver API to use a message list
- Correct bogus address len code (was confused with chip address length)
- Drop extra call to i2c_bind_driver() in i2c_probe()
Changes in v2:
- Add a 'deblock' method to recover an I2C bus stuck in mid-transaction
- Add a helper function to find a chip on a particular bus number
- Add some debugging for generic I2C device binding
- Fix cihp typo
- Implement generic I2C devices to allow 'i2c probe' on unknown devices
- Return the probed device from i2c_probe()
- Set the bus speed after the bus is probed
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-uclass.c | 466 +
include/config_fallbacks.h | 6 +
include/dm/uclass-id.h | 2 +
include/i2c.h | 352 ++
5 files changed, 827 insertions(+)
create mode 100644 drivers/i2c/i2c-uclass.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index dae3d71..063e097 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -4,6 +4,7 @@
#
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_DM_I2C) += i2c-uclass.o
obj-$(CONFIG_SYS_I2C_ADI) += adi_i2c.o
obj-$(CONFIG_I2C_MV) += mv_i2c.o
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
new file mode 100644
index 000..005bf86
--- /dev/null
+++ b/drivers/i2c/i2c-uclass.c
@@ -0,0 +1,466 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include fdtdec.h
+#include i2c.h
+#include malloc.h
+#include dm/device-internal.h
+#include dm/lists.h
+#include dm/root.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define I2C_MAX_OFFSET_LEN 4
+
+/**
+ * i2c_setup_offset() - Set up a new message with a chip offset
+ *
+ * @chip: Chip to use
+ * @offset:Byte offset within chip
+ * @offset_buf:Place to put byte offset
+ * @msg: Message buffer
+ * @return 0 if OK, -EADDRNOTAVAIL if the offset length is 0. In that case the
+ * message is still set up but will not contain an offset.
+ */
+static int i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
+ uint8_t offset_buf[], struct i2c_msg *msg)
+{
+ int offset_len;
+
+ msg-addr = chip-chip_addr;
+ msg-flags = chip-flags DM_I2C_CHIP_10BIT ? I2C_M_TEN : 0;
+ msg-len = chip-offset_len;
+ msg-buf = offset_buf;
+ if (!chip-offset_len)
+ return -EADDRNOTAVAIL;
+ assert(chip-offset_len = I2C_MAX_OFFSET_LEN);
+ offset_len = chip-offset_len;
+ while (offset_len--)
+ *offset_buf++ = offset (8 * offset_len);
+
+ return 0;
+}
+
+static int i2c_read_bytewise(struct udevice *dev, uint offset,
+uint8_t *buffer, int len)
+{
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ struct udevice *bus = dev_get_parent(dev);
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct i2c_msg msg[2], *ptr;
+ uint8_t offset_buf[I2C_MAX_OFFSET_LEN];
+ int ret;
+ int i;
+
+ for (i = 0; i len; i++) {
+ if (i2c_setup_offset(chip, offset + i, offset_buf, msg))
+ return -EINVAL;
+ ptr = msg + 1;
+ ptr-addr = chip-chip_addr;
+ ptr-flags = msg-flags |
[U-Boot] [PATCH v5 06/11] dm: i2c: config: Enable I2C for sandbox using driver model
Enable the options to bring up I2C on sandbox. Also enable all the available I2C commands for testing purposes. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Heiko Schocher h...@denx.de --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/configs/sandbox.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 2b03841..657f751 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -112,6 +112,12 @@ #define CONFIG_SPI_FLASH_STMICRO #define CONFIG_SPI_FLASH_WINBOND +#define CONFIG_DM_I2C +#define CONFIG_CMD_I2C +#define CONFIG_SYS_I2C_SANDBOX +#define CONFIG_I2C_EDID +#define CONFIG_I2C_EEPROM + /* Memory things - we don't really want a memory test */ #define CONFIG_SYS_LOAD_ADDR 0x #define CONFIG_SYS_MEMTEST_START 0x0010 -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 05/11] dm: i2c: Add an I2C EEPROM simulator
To enable testing of I2C, add a simple I2C EEPROM simulator for sandbox.
It supports reading and writing from a small data store.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5: None
Changes in v4:
- Add a probe_chip() method for the eeprom
- Add a remove() method for the eeprom
- Add an eeprom test mode
- Add eeprom debugging output
- Add support for eeprom offset length
Changes in v3:
- Update emulator for new uclass interface
Changes in v2: None
arch/sandbox/include/asm/test.h | 26 ++
drivers/misc/Makefile | 3 +
drivers/misc/i2c_eeprom_emul.c | 176
3 files changed, 205 insertions(+)
create mode 100644 arch/sandbox/include/asm/test.h
create mode 100644 drivers/misc/i2c_eeprom_emul.c
diff --git a/arch/sandbox/include/asm/test.h b/arch/sandbox/include/asm/test.h
new file mode 100644
index 000..25a0c85
--- /dev/null
+++ b/arch/sandbox/include/asm/test.h
@@ -0,0 +1,26 @@
+/*
+ * Test-related constants for sandbox
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_TEST_H
+#define __ASM_TEST_H
+
+/* The sandbox driver always permits an I2C device with this address */
+#define SANDBOX_I2C_TEST_ADDR 0x59
+
+enum sandbox_i2c_eeprom_test_mode {
+ SIE_TEST_MODE_NONE,
+ /* Permits read/write of only one byte per I2C transaction */
+ SIE_TEST_MODE_SINGLE_BYTE,
+};
+
+void sandbox_i2c_eeprom_set_test_mode(struct udevice *dev,
+ enum sandbox_i2c_eeprom_test_mode mode);
+
+void sandbox_i2c_eeprom_set_offset_len(struct udevice *dev, int offset_len);
+
+#endif
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2f2e48f..ff02184 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,9 @@ obj-$(CONFIG_MXC_OCOTP) += mxc_ocotp.o
obj-$(CONFIG_MXS_OCOTP) += mxs_ocotp.o
obj-$(CONFIG_NS87308) += ns87308.o
obj-$(CONFIG_PDSP188x) += pdsp188x.o
+ifdef CONFIG_DM_I2C
+obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o
+endif
obj-$(CONFIG_STATUS_LED) += status_led.o
obj-$(CONFIG_TWL4030_LED) += twl4030_led.o
obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
diff --git a/drivers/misc/i2c_eeprom_emul.c b/drivers/misc/i2c_eeprom_emul.c
new file mode 100644
index 000..3e370aa
--- /dev/null
+++ b/drivers/misc/i2c_eeprom_emul.c
@@ -0,0 +1,176 @@
+/*
+ * Simulate an I2C eeprom
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include fdtdec.h
+#include i2c.h
+#include malloc.h
+#include asm/test.h
+
+#ifdef DEBUG
+#define debug_buffer print_buffer
+#else
+#define debug_buffer(x, ...)
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sandbox_i2c_flash_plat_data {
+ enum sandbox_i2c_eeprom_test_mode test_mode;
+ const char *filename;
+ int offset_len; /* Length of an offset in bytes */
+ int size; /* Size of data buffer */
+};
+
+struct sandbox_i2c_flash {
+ uint8_t *data;
+};
+
+void sandbox_i2c_eeprom_set_test_mode(struct udevice *dev,
+ enum sandbox_i2c_eeprom_test_mode mode)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+
+ plat-test_mode = mode;
+}
+
+void sandbox_i2c_eeprom_set_offset_len(struct udevice *dev, int offset_len)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+
+ plat-offset_len = offset_len;
+}
+
+static int sandbox_i2c_eeprom_xfer(struct udevice *emul, struct i2c_msg *msg,
+ int nmsgs)
+{
+ struct sandbox_i2c_flash *priv = dev_get_priv(emul);
+ uint offset = 0;
+
+ debug(\n%s\n, __func__);
+ debug_buffer(0, priv-data, 1, 16, 0);
+ for (; nmsgs 0; nmsgs--, msg++) {
+ struct sandbox_i2c_flash_plat_data *plat =
+ dev_get_platdata(emul);
+ int len;
+ u8 *ptr;
+
+ if (!plat-size)
+ return -ENODEV;
+ if (msg-addr + msg-len plat-size) {
+ debug(%s: Address %x, len %x is outside range 0..%x\n,
+ __func__, msg-addr, msg-len, plat-size);
+ return -EINVAL;
+ }
+ len = msg-len;
+ debug( %s: msg-len=%d,
+ msg-flags I2C_M_RD ? read : write,
+ msg-len);
+ if (msg-flags I2C_M_RD) {
+ if (plat-test_mode == SIE_TEST_MODE_SINGLE_BYTE)
+ len = 1;
+ debug(, offset %x, len %x: , offset, len);
+ memcpy(msg-buf, priv-data + offset, len);
+ memset(msg-buf + len, '\xff', msg-len - len);
+ debug_buffer(0, msg-buf, 1, msg-len, 0);
+ } else if (len =
[U-Boot] [PATCH v5 09/11] dm: i2c: Add tests for I2C
Add some basic tests to check that the system works as expected.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Heiko Schocher h...@denx.de
---
Changes in v5:
- Adjust tests for DM_I2C_CHIP_RE_ADDRESS split
Changes in v4:
- Add an assert for non-null
- Add tests for offset length
- Adjust tests to match uclass changes
Changes in v3:
- Update for new uclass = emulateor interface
Changes in v2:
- Add a new asm/test.h header for tests in sandbox
- Add a test for automatic binding of generic I2C devices
include/dm/ut.h | 12
test/dm/Makefile | 1 +
test/dm/i2c.c| 216 +++
test/dm/test.dts | 17 +
4 files changed, 246 insertions(+)
create mode 100644 test/dm/i2c.c
diff --git a/include/dm/ut.h b/include/dm/ut.h
index fa9eac0..ec61465 100644
--- a/include/dm/ut.h
+++ b/include/dm/ut.h
@@ -89,6 +89,18 @@ void ut_failf(struct dm_test_state *dms, const char *fname,
int line,
} \
}
+/* Assert that a pointer is not NULL */
+#define ut_assertnonnull(expr) { \
+ const void *val = (expr); \
+ \
+ if (val == NULL) { \
+ ut_failf(dms, __FILE__, __LINE__, __func__, \
+#expr = NULL, \
+Expected non-null, got NULL);\
+ return -1; \
+ } \
+}
+
/* Assert that an operation succeeds (returns 0) */
#define ut_assertok(cond) ut_asserteq(0, cond)
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 75d3d41..612aa95 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -20,4 +20,5 @@ ifneq ($(CONFIG_SANDBOX),)
obj-$(CONFIG_DM_GPIO) += gpio.o
obj-$(CONFIG_DM_SPI) += spi.o
obj-$(CONFIG_DM_SPI_FLASH) += sf.o
+obj-$(CONFIG_DM_I2C) += i2c.o
endif
diff --git a/test/dm/i2c.c b/test/dm/i2c.c
new file mode 100644
index 000..a53e28d
--- /dev/null
+++ b/test/dm/i2c.c
@@ -0,0 +1,216 @@
+/*
+ * Copyright (C) 2013 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note: Test coverage does not include 10-bit addressing
+ */
+
+#include common.h
+#include dm.h
+#include fdtdec.h
+#include i2c.h
+#include dm/device-internal.h
+#include dm/test.h
+#include dm/uclass-internal.h
+#include dm/ut.h
+#include dm/util.h
+#include asm/state.h
+#include asm/test.h
+
+static const int busnum;
+static const int chip = 0x2c;
+
+/* Test that we can find buses and chips */
+static int dm_test_i2c_find(struct dm_test_state *dms)
+{
+ struct udevice *bus, *dev;
+ const int no_chip = 0x10;
+
+ ut_asserteq(-ENODEV, uclass_find_device_by_seq(UCLASS_I2C, busnum,
+ false, bus));
+
+ /*
+* i2c_post_bind() will bind devices to chip selects. Check this then
+* remove the emulation and the slave device.
+*/
+ ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+ ut_assertok(i2c_probe(bus, chip, 0, dev));
+ ut_asserteq(-ENODEV, i2c_probe(bus, no_chip, 0, dev));
+ ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_I2C, 1, bus));
+
+ return 0;
+}
+DM_TEST(dm_test_i2c_find, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_read_write(struct dm_test_state *dms)
+{
+ struct udevice *bus, *dev;
+ uint8_t buf[5];
+
+ ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+ ut_assertok(i2c_get_chip(bus, chip, dev));
+ ut_assertok(i2c_read(dev, 0, buf, 5));
+ ut_assertok(memcmp(buf, \0\0\0\0\0, sizeof(buf)));
+ ut_assertok(i2c_write(dev, 2, (uint8_t *)AB, 2));
+ ut_assertok(i2c_read(dev, 0, buf, 5));
+ ut_assertok(memcmp(buf, \0\0AB\0, sizeof(buf)));
+
+ return 0;
+}
+DM_TEST(dm_test_i2c_read_write, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_speed(struct dm_test_state *dms)
+{
+ struct udevice *bus, *dev;
+ uint8_t buf[5];
+
+ ut_assertok(uclass_get_device_by_seq(UCLASS_I2C, busnum, bus));
+ ut_assertok(i2c_get_chip(bus, chip, dev));
+ ut_assertok(i2c_set_bus_speed(bus, 10));
+ ut_assertok(i2c_read(dev, 0, buf, 5));
+ ut_assertok(i2c_set_bus_speed(bus, 40));
+ ut_asserteq(40, i2c_get_bus_speed(bus));
+ ut_assertok(i2c_read(dev, 0, buf, 5));
+ ut_asserteq(-EINVAL, i2c_write(dev, 0, buf, 5));
+
+ return 0;
+}
+DM_TEST(dm_test_i2c_speed, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
+
+static int dm_test_i2c_offset_len(struct dm_test_state *dms)
+{
+ struct udevice *bus, *dev;
+ uint8_t buf[5];
+
+
[U-Boot] [PATCH v5 11/11] dm: i2c: tegra: Convert to driver model
This converts all Tegra boards over to use driver model for I2C. The driver
is adjusted to use driver model and the following obsolete CONFIGs are
removed:
- CONFIG_SYS_I2C_INIT_BOARD
- CONFIG_I2C_MULTI_BUS
- CONFIG_SYS_MAX_I2C_BUS
- CONFIG_SYS_I2C_SPEED
- CONFIG_SYS_I2C
This has been tested on:
- trimslice (no I2C)
- beaver
- Jetson-TK1
It has not been tested on Tegra 114 as I don't have that board.
Acked-by: Heiko Schocher h...@denx.de
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4:
- Add probe_chip() method
Changes in v3:
- Change driver to support new message-based I2C uclass API
Changes in v2:
- Adjust tegra_i2c_child_pre_probe() to permit generic I2C devices
- Correct the compatible strings for I2C buses
- Don't init if the speed is 0, since this breaks the controller
- Expand coverage to all Tegra boards
arch/arm/cpu/tegra20-common/pmu.c | 21 +-
arch/arm/dts/tegra124-jetson-tk1.dts| 1 -
arch/arm/dts/tegra30-tec-ng.dts | 4 +
arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +-
board/avionic-design/common/tamonten-ng.c | 12 +-
board/nvidia/cardhu/cardhu.c| 13 +-
board/nvidia/common/board.c | 4 -
board/nvidia/dalmore/dalmore.c | 21 +-
board/nvidia/whistler/whistler.c| 29 ++-
board/toradex/apalis_t30/apalis_t30.c | 19 +-
drivers/i2c/tegra_i2c.c | 366 +---
drivers/power/tps6586x.c| 27 +-
include/configs/apalis_t30.h| 3 -
include/configs/beaver.h| 3 -
include/configs/cardhu.h| 5 -
include/configs/colibri_t30.h | 3 -
include/configs/dalmore.h | 5 -
include/configs/jetson-tk1.h| 5 -
include/configs/nyan-big.h | 5 -
include/configs/seaboard.h | 3 -
include/configs/tec-ng.h| 5 -
include/configs/tegra-common.h | 1 +
include/configs/tegra114-common.h | 3 -
include/configs/tegra124-common.h | 3 -
include/configs/tegra20-common.h| 3 -
include/configs/tegra30-common.h| 3 -
include/configs/trimslice.h | 3 -
include/configs/venice2.h | 5 -
include/configs/whistler.h | 3 -
include/tps6586x.h | 4 +-
30 files changed, 210 insertions(+), 374 deletions(-)
diff --git a/arch/arm/cpu/tegra20-common/pmu.c
b/arch/arm/cpu/tegra20-common/pmu.c
index c595f70..36a76a2 100644
--- a/arch/arm/cpu/tegra20-common/pmu.c
+++ b/arch/arm/cpu/tegra20-common/pmu.c
@@ -6,6 +6,7 @@
*/
#include common.h
+#include i2c.h
#include tps6586x.h
#include asm/io.h
#include asm/arch/tegra.h
@@ -23,9 +24,13 @@
#define VDD_TRANSITION_STEP0x06/* 150mv */
#define VDD_TRANSITION_RATE0x06/* 3.52mv/us */
+#define PMI_I2C_ADDRESS0x34/* chip requires this address */
+
int pmu_set_nominal(void)
{
- int core, cpu, bus;
+ struct udevice *bus, *dev;
+ int core, cpu;
+ int ret;
/* by default, the table has been filled with T25 settings */
switch (tegra_get_chip_sku()) {
@@ -42,12 +47,18 @@ int pmu_set_nominal(void)
return -1;
}
- bus = tegra_i2c_get_dvc_bus_num();
- if (bus == -1) {
+ ret = tegra_i2c_get_dvc_bus(bus);
+ if (ret) {
debug(%s: Cannot find DVC I2C bus\n, __func__);
- return -1;
+ return ret;
}
- tps6586x_init(bus);
+ ret = i2c_get_chip(bus, PMI_I2C_ADDRESS, dev);
+ if (ret) {
+ debug(%s: Cannot find DVC I2C chip\n, __func__);
+ return ret;
+ }
+
+ tps6586x_init(dev);
tps6586x_set_pwm_mode(TPS6586X_PWM_SM1);
return tps6586x_adjust_sm0_sm1(core, cpu, VDD_TRANSITION_STEP,
VDD_TRANSITION_RATE, VDD_RELATION);
diff --git a/arch/arm/dts/tegra124-jetson-tk1.dts
b/arch/arm/dts/tegra124-jetson-tk1.dts
index ffad116..f6fe9a0 100644
--- a/arch/arm/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/dts/tegra124-jetson-tk1.dts
@@ -16,7 +16,6 @@
i2c2 = /i2c@7000c400;
i2c3 = /i2c@7000c500;
i2c4 = /i2c@7000c700;
- i2c5 = /i2c@7000d100;
sdhci0 = /sdhci@700b0600;
sdhci1 = /sdhci@700b0400;
spi0 = /spi@7000d400;
diff --git a/arch/arm/dts/tegra30-tec-ng.dts b/arch/arm/dts/tegra30-tec-ng.dts
index 8a69e81..e924acc 100644
--- a/arch/arm/dts/tegra30-tec-ng.dts
+++ b/arch/arm/dts/tegra30-tec-ng.dts
@@ -6,6 +6,10 @@
model = Avionic Design Tamonten™ NG Evaluation Carrier;
compatible = ad,tec-ng, nvidia,tegra30;
+ aliases {
+ i2c0 = /i2c@7000c400;
+ };
+
/* GEN2
Re: [U-Boot] [PATCH 4/5] exynos5420: Add LCD and LED powerup settings for peach-pi
On Fri, 2014-12-05 at 19:43 +0530, Ajay Kumar wrote:
Add code to support powerup sequence for peach-pi LCD.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
board/samsung/smdk5420/smdk5420.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/smdk5420/smdk5420.c
index a691222..915125e 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -73,19 +73,24 @@ void exynos_lcd_power_on(void)
mdelay(5);
- /* TODO(ajaykumar...@samsung.com): Use device tree */
- gpio_request(EXYNOS5420_GPIO_X35, edp_slp#);
- gpio_direction_output(EXYNOS5420_GPIO_X35, 1); /* EDP_SLP# */
- mdelay(10);
- gpio_request(EXYNOS5420_GPIO_Y77, edp_rst#);
- gpio_direction_output(EXYNOS5420_GPIO_Y77, 1); /* EDP_RST# */
- gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
- gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
- gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
-
- if (has_edp_bridge())
+ if (has_edp_bridge()) {
+ /* TODO(ajaykumar...@samsung.com): Use device tree */
+ gpio_request(EXYNOS5420_GPIO_X35, edp_slp#);
+ gpio_direction_output(EXYNOS5420_GPIO_X35, 1); /* EDP_SLP# */
+ mdelay(10);
+ gpio_request(EXYNOS5420_GPIO_Y77, edp_rst#);
+ gpio_direction_output(EXYNOS5420_GPIO_Y77, 1); /* EDP_RST# */
+ gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
+ gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
+ gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
+
if (parade_init(gd-fdt_blob))
printf(%s: ps8625_init() failed\n, __func__);
+ } else {
+ gpio_request(EXYNOS5420_GPIO_X26, edp_hpd);
+ gpio_direction_input(EXYNOS5420_GPIO_X26); /* EDP_HPD */
+ gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
+ }
Any chance you could switch to using device-tree while changing this
area. On SMDK5420 and XU3 EXYNOS5420_GPIO_X26 is used for USB so there
is a bit of a potentially nastly clash there.
--
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] arm: marvell: add LIBFDT support to sheevaplug
Hi Prafulla, Without LIBFDT feature, all newer kernel are unusable ! I agree with a review may be needed with : [PATCH v3 2/2] arm: marvell: fix ENV and MTDPARTS for sheevaplug is there any problem with : [PATCH v3 1/2] arm: marvell: add LIBFDT support to sheevaplug Regards, Gérald Le 25/10/2014 07:54, Gerald Kerma a écrit : This patch add LIBFDT support to Marvell Sheevaplug Changes in v2: - mainline rebased Changes in v1: - add LIBFDT support Signed-off-by: Gerald Kerma drea...@doukki.net --- include/configs/sheevaplug.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h index 71be823..247789c 100644 --- a/include/configs/sheevaplug.h +++ b/include/configs/sheevaplug.h @@ -49,6 +49,12 @@ #define CONFIG_CMD_NAND #define CONFIG_CMD_PING #define CONFIG_CMD_USB + +/* +* Enable device tree support +*/ +#define CONFIG_OF_LIBFDT + /* * mv-common.h should be defined after CMD configs since it used them * to enable certain macros 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] Please pull u-boot-mpc85xx master
Tom, The following changes since commit 38cd8c4253013ccdd4052ee021f6066fe9a52551: Merge branch 'master' of git://git.denx.de/u-boot-mips (2014-11-27 10:49:38 -0500) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to af7219de2c66b64ddae0348b3d3fa5072d800dd2: powerpc/hydra: fix judging condition of RGMII selection (2014-12-05 08:06:17 -0800) Alison Wang (1): common: spl: Add interactive DDR debugger support for SPL image Chunhe Lan (3): powerpc/p1023rdb: Enable configs to use generic board code powerpc/c29xpcie: Enable configs to use generic board code powerpc/hydra: Update MDIO mux fixups Heiko Schocher (1): powerpc, muas3001: remove CONFIG_SYS_RAMBOOT Holger Brunck (1): km/km82xx: remove CONFIG_SYS_RAMBOOT Joakim Tjernlund (1): Freescale t104x: Do not exclude SGMII Minghuan Lian (1): powerpc/hydra: fix judging condition of RGMII selection Prabhakar Kushwaha (2): powerpc/mpc85xx:Put errata number for T104x NAND boot issue board/t104xrdb: Conditional workaround of errata A-008044 Priyanka Jain (1): powerpc/mpc85xx: Update LIODN entries for T1040 Shaohui Xie (4): powerpc/P5040DS: enable SATA support powerpc/b4860qds: add xfi support powerpc/b4860qds: dtb fixup for xfi powerpc/b4860qds: add workaround for XFI Shaveta Leekha (4): powerpc/b4860: Enable law creation of MAPLE 85xx/b4860: Add alternate serdes protocols for B4860/B4420 B4860QDS: SGMII related updates B4860: Add alternate LC VCO serdes protocols support in board file Shengzhou Liu (11): powerpc/t2080: add serdes2 protocol 0x2e net/phy: Add support for CS4315/CS4340 PHY powerpc/t2080: updating rcw for silicon v1.1 powerpc/mpc85xx: Add T1024/T1023 SoC support powerpc/t1024qds: Add T1024 QDS board support powerpc/t1024rdb: Add T1024 RDB board support net/fman: update 10GEC to fit new SoC board/t1024qds: update pin multiplexing net/phy: enable serdes auto-negotiation for vsc8514 phy t1024qds: increase IO drive strength board/t1024qds: add retimer support on t1024qds Suresh Gupta (2): B4860QDS: Enable SFP or AMC on basis of hwconfig string B4860QDS: Enable enet port as per fsl_b4860_serdes2 string in hwconfig Tang Yuantian (1): mpc85xx/p1022ds: convert to generic board Tudor Laurentiu (1): powerpc/mpc85xx: use correct dma compatible for several SoCs Xiaobo Xie (1): powerpc/t4240rdb: enable eSDHC 3.3V support Ying Zhang (3): powerpc/t208xqds: VID support board/freescale: use generic board architecture for p1025-twr board/freescale: use generic board architecture for p1010rdb York Sun (5): mpc85xx/t208xqds: Adjust DDR timing parameters mpc85xx/t2080: Fix parsing DDR ratio for new revision powerpc/t1040qds: Update DDR option driver/ddr/fsl: Adjust timing_cfg_0 to better support two DDR slots driver/ddr/fsl: Add workaround for faulty SPD Zhao Qiang (1): powerpc/mpc85xx: modify erratum A007186 vijay rai (1): powerpc/t104x: Convert to use generic board code README |4 + arch/powerpc/cpu/mpc85xx/Kconfig | 10 + arch/powerpc/cpu/mpc85xx/Makefile |4 + arch/powerpc/cpu/mpc85xx/b4860_ids.c |4 +- arch/powerpc/cpu/mpc85xx/b4860_serdes.c| 19 + arch/powerpc/cpu/mpc85xx/cmd_errata.c | 11 +- arch/powerpc/cpu/mpc85xx/fsl_corenet2_serdes.c |3 +- arch/powerpc/cpu/mpc85xx/p2041_ids.c |4 +- arch/powerpc/cpu/mpc85xx/p3041_ids.c |4 +- arch/powerpc/cpu/mpc85xx/p4080_ids.c |4 +- arch/powerpc/cpu/mpc85xx/p5020_ids.c |4 +- arch/powerpc/cpu/mpc85xx/p5040_ids.c |4 +- arch/powerpc/cpu/mpc85xx/speed.c | 35 +- arch/powerpc/cpu/mpc85xx/t1024_ids.c | 82 +++ arch/powerpc/cpu/mpc85xx/t1024_serdes.c| 52 ++ arch/powerpc/cpu/mpc85xx/t1040_ids.c | 30 +- arch/powerpc/cpu/mpc85xx/t2080_ids.c |6 +- arch/powerpc/cpu/mpc85xx/t2080_serdes.c|1 + arch/powerpc/cpu/mpc85xx/t4240_ids.c |4 +- arch/powerpc/cpu/mpc8xxx/cpu.c |4 + arch/powerpc/include/asm/config_mpc85xx.h | 47 ++ arch/powerpc/include/asm/fsl_errata.h | 24 + arch/powerpc/include/asm/fsl_liodn.h |4 +- arch/powerpc/include/asm/fsl_secure_boot.h |4 +- arch/powerpc/include/asm/immap_85xx.h | 22 + arch/powerpc/include/asm/processor.h |4 + board/freescale/b4860qds/b4860qds.c| 95 ++- board/freescale/b4860qds/eth_b4860qds.c| 127 +++- board/freescale/b4860qds/law.c |3 - board/freescale/common/Makefile
Re: [U-Boot] [PATCH v5 1/3] dts: Bring in Chrome OS keyboard device tree definition
Hey Simon,
On Thu, 2014-12-04 at 06:36 -0700, Simon Glass wrote:
This will be used by nyan-big, but bring it in in a separate patch since it
will be common to other boards.
Signed-off-by: Simon Glass s...@chromium.org
This will clash with the patch i sent last week to pull (sorry i didn't
see your v3 for this earlier) in this dtsi its documentation fix
the existing exynos users/code to correctly use it..
I'm not very familiar with how the u-boot merging process works, so i
wonder how to best get these patches merged without unnecessary
conflicts between e.g. the samsung/tegra trees.
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add patch to bring in cros-ec-keyboard.dtsi
Changes in v2: None
arch/arm/dts/cros-ec-keyboard.dtsi | 105
+
1 file changed, 105 insertions(+)
create mode 100644 arch/arm/dts/cros-ec-keyboard.dtsi
diff --git a/arch/arm/dts/cros-ec-keyboard.dtsi
b/arch/arm/dts/cros-ec-keyboard.dtsi
new file mode 100644
index 000..9c7fb0a
--- /dev/null
+++ b/arch/arm/dts/cros-ec-keyboard.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Keyboard dts fragment for devices that use cros-ec-keyboard
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include dt-bindings/input/input.h
+
+cros_ec {
+ keyboard-controller {
+ compatible = google,cros-ec-keyb;
+ keypad,num-rows = 8;
+ keypad,num-columns = 13;
+ google,needs-ghost-filter;
+
+ linux,keymap =
+ MATRIX_KEY(0x00, 0x01, KEY_LEFTMETA)
+ MATRIX_KEY(0x00, 0x02, KEY_F1)
+ MATRIX_KEY(0x00, 0x03, KEY_B)
+ MATRIX_KEY(0x00, 0x04, KEY_F10)
+ MATRIX_KEY(0x00, 0x06, KEY_N)
+ MATRIX_KEY(0x00, 0x08, KEY_EQUAL)
+ MATRIX_KEY(0x00, 0x0a, KEY_RIGHTALT)
+
+ MATRIX_KEY(0x01, 0x01, KEY_ESC)
+ MATRIX_KEY(0x01, 0x02, KEY_F4)
+ MATRIX_KEY(0x01, 0x03, KEY_G)
+ MATRIX_KEY(0x01, 0x04, KEY_F7)
+ MATRIX_KEY(0x01, 0x06, KEY_H)
+ MATRIX_KEY(0x01, 0x08, KEY_APOSTROPHE)
+ MATRIX_KEY(0x01, 0x09, KEY_F9)
+ MATRIX_KEY(0x01, 0x0b, KEY_BACKSPACE)
+
+ MATRIX_KEY(0x02, 0x00, KEY_LEFTCTRL)
+ MATRIX_KEY(0x02, 0x01, KEY_TAB)
+ MATRIX_KEY(0x02, 0x02, KEY_F3)
+ MATRIX_KEY(0x02, 0x03, KEY_T)
+ MATRIX_KEY(0x02, 0x04, KEY_F6)
+ MATRIX_KEY(0x02, 0x05, KEY_RIGHTBRACE)
+ MATRIX_KEY(0x02, 0x06, KEY_Y)
+ MATRIX_KEY(0x02, 0x07, KEY_102ND)
+ MATRIX_KEY(0x02, 0x08, KEY_LEFTBRACE)
+ MATRIX_KEY(0x02, 0x09, KEY_F8)
+
+ MATRIX_KEY(0x03, 0x01, KEY_GRAVE)
+ MATRIX_KEY(0x03, 0x02, KEY_F2)
+ MATRIX_KEY(0x03, 0x03, KEY_5)
+ MATRIX_KEY(0x03, 0x04, KEY_F5)
+ MATRIX_KEY(0x03, 0x06, KEY_6)
+ MATRIX_KEY(0x03, 0x08, KEY_MINUS)
+ MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH)
+
+ MATRIX_KEY(0x04, 0x00, KEY_RIGHTCTRL)
+ MATRIX_KEY(0x04, 0x01, KEY_A)
+ MATRIX_KEY(0x04, 0x02, KEY_D)
+ MATRIX_KEY(0x04, 0x03, KEY_F)
+ MATRIX_KEY(0x04, 0x04, KEY_S)
+ MATRIX_KEY(0x04, 0x05, KEY_K)
+ MATRIX_KEY(0x04, 0x06, KEY_J)
+ MATRIX_KEY(0x04, 0x08, KEY_SEMICOLON)
+ MATRIX_KEY(0x04, 0x09, KEY_L)
+ MATRIX_KEY(0x04, 0x0a, KEY_BACKSLASH)
+ MATRIX_KEY(0x04, 0x0b, KEY_ENTER)
+
+ MATRIX_KEY(0x05, 0x01, KEY_Z)
+ MATRIX_KEY(0x05, 0x02, KEY_C)
+ MATRIX_KEY(0x05, 0x03, KEY_V)
+ MATRIX_KEY(0x05, 0x04, KEY_X)
+ MATRIX_KEY(0x05, 0x05, KEY_COMMA)
+ MATRIX_KEY(0x05, 0x06, KEY_M)
+ MATRIX_KEY(0x05, 0x07, KEY_LEFTSHIFT)
+ MATRIX_KEY(0x05, 0x08, KEY_SLASH)
+ MATRIX_KEY(0x05, 0x09, KEY_DOT)
+ MATRIX_KEY(0x05, 0x0b, KEY_SPACE)
+
+ MATRIX_KEY(0x06, 0x01, KEY_1)
+ MATRIX_KEY(0x06, 0x02, KEY_3)
+ MATRIX_KEY(0x06, 0x03, KEY_4)
+ MATRIX_KEY(0x06, 0x04, KEY_2)
+ MATRIX_KEY(0x06, 0x05, KEY_8)
+ MATRIX_KEY(0x06,
Re: [U-Boot] [PATCH] Freescale t104x: Do not exclude SGMII
On 10/24/2014 07:49 AM, Joakim Tjernlund wrote: fman_port_enet_if() tests if FM1_DTSEC2 or FM1_DTSEC4 uses RGMII or MII and if not returns PHY_INTERFACE_MODE_NONE. This excludes testing for SGMII further down. Remove the unconditional else return PHY_INTERFACE_MODE_NONE so SGMII can be tested too. Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se --- Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/t2080: add serdes2 protocol 0x2e
On 10/26/2014 07:08 PM, Shengzhou Liu wrote: Add serdes2 protocol 0x2e. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2][v2] powerpc/mpc85xx:Put errata number for T104x NAND boot issue
On 10/29/2014 10:03 AM, Prabhakar Kushwaha wrote: When device is configured to load RCW from NAND flash IFC_A[16:31] are driven low after RCW loading. Hence Devices connected on IFC_CS[1:7] and using IFC_A[16:31] lines are not accessible. Workaround is already in-place. Put the errata number to adhere errata handling framework. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2: - updated CONFIG_A08044_WORKAROUND to CONFIG_A008044_WORKAROUND Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2][v2] board/t104xrdb: Conditional workaround of errata A-008044
On 10/29/2014 10:03 AM, Prabhakar Kushwaha wrote: Workaround of Errata A-008044 was implemented without errata number and it is enabled by default. Errata A-008044 is only valid for T1040 Rev 1.0. So put errata number and make it conditional. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2: - updated CONFIG_A08044_WORKAROUND to CONFIG_A008044_WORKAROUND Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] powerpc/mpc85xx: modify erratum A007186
On 10/29/2014 11:07 PM, Zhao Qiang wrote:
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang b45...@freescale.com
Change-Id: I19d794283229a86d04d8f22d44b860a5c3940cdc
Reviewed-on: http://git.am.freescale.net:8181/19850
Tested-by: Review Code-CDREVIEW cdrev...@freescale.com
Reviewed-by: Yusong Sun york...@freescale.com
---
Changes for v2:
- use has_errata_a007186 instead of not_has_errata_a007186
Changes for v3:
- use if (has_erratum_a007186() sel == 0x01 || sel == 0x02) {
- instead of if (has_erratum_a007186()) {
Changes for v4:
- update soc info in has_erratum_a007186 function
Applied to u-boot-mpc85xx, awaiting upstream.
York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/t208xqds: VID support
On 10/31/2014 03:06 AM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com The fuse status register provides the values from on-chip voltage ID efuses programmed at the factory. These values define the voltage requirements for the chip. u-boot reads FUSESR and translates the values into the appropriate commands to set the voltage output value of an external voltage regulator. Signed-off-by: Ying Zhang b40...@freescale.com --- Change from v1: - Set the core voltage according to the VID on startup. Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/freescale: use generic board architecture for p1025-twr
On 11/03/2014 11:10 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com Use generic board architecture for p1025-twr, tested with NOR boot and NAND boot on p1025-twr. Signed-off-by: Ying Zhang b40...@freescale.com --- Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/freescale: use generic board architecture for p1010rdb
On 11/05/2014 09:05 PM, ying.zh...@freescale.com wrote: From: Ying Zhang b40...@freescale.com Use generic board architecture for p1010rdb, tested with NOR boot on p1010rdb-pb. Signed-off-by: Ying Zhang b40...@freescale.com --- Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/P5040DS: enable SATA support
On 11/04/2014 03:53 AM, shh@gmail.com wrote: From: Shaohui Xie shaohui@freescale.com The define CONFIG_FSL_SATA_V2 is missing, so SATA is not available in U-boot. Signed-off-by: Shaohui Xie shaohui@freescale.com --- Applied to u-boot-mpc85xx, awaiting upstream. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
