Re: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena
On 12/10/2014 05:04, Fabio Estevam wrote: On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross x...@kosagi.com wrote: Ok, understood. Just curious: which Ethernet PHY is used on the novena board? It's the same Micrel PHY used on the Sabrelite, the KSZ9021. nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in accordance with ksz9021 datasheet. Shouldn't we wait 10ms here as well? The reference manual for the PHY indicates that you should hold reset low for 10ms after the supply voltage stabilizes. So long as it takes at least 10msto get from the point at which the CPU starts executing its ROM code to the point at which the reset line is toggled, we will be fine. Sean ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] ARM: mxs: tools: Add support for boot progress display flag
mkimage -T mxs now support new flag in config file:
DISPLAYPROGRESS - makes boot process print HTLLC characters for each BootROM
instruction.
Signed-off-by: Alexey Ignatov lexsz...@gmail.com
---
arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg | 1 +
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg | 1 +
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg | 1 +
doc/README.mxsimage| 13 +
tools/mxsimage.c | 16 ++--
tools/mxsimage.h | 5 +++--
6 files changed, 25 insertions(+), 12 deletions(-)
Changes in v4:
- minor fix, removed parentheses in SB_IMAGE_FLAGS_MASK definition
Changes in v3:
- removed VERBOSEPROGRESS flag
- added DISPLAYPROGRESS flag to default mkimage configs, added documentation
v2 contained an error, don't use it.
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg
b/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg
index 1520bba..83953da 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg
+++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage-signed.cfg
@@ -1,3 +1,4 @@
+DISPLAYPROGRESS
SECTION 0x0 BOOTABLE
TAG LAST
LOAD 0x1000 spl/u-boot-spl.bin
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
index 55510e9..e702809 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
+++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
@@ -1,3 +1,4 @@
+DISPLAYPROGRESS
SECTION 0x0 BOOTABLE
TAG LAST
LOAD 0x1000 spl/u-boot-spl.bin
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
index bb78cb0..3f7bf59 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
+++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
@@ -1,3 +1,4 @@
+DISPLAYPROGRESS
SECTION 0x0 BOOTABLE
TAG LAST
LOAD 0x1000 spl/u-boot-spl.bin
diff --git a/doc/README.mxsimage b/doc/README.mxsimage
index 0d31cba..c3975ee 100644
--- a/doc/README.mxsimage
+++ b/doc/README.mxsimage
@@ -27,7 +27,7 @@ These semantics and rules will be outlined now.
- Each line of the configuration file contains exactly one instruction.
- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
- The configuration file is a concatenation of blocks called sections and
- optionally DCD blocks (see below).
+ optionally DCD blocks (see below), and optional flags lines.
- Each section is started by the SECTION instruction.
- The SECTION instruction has the following semantics:
@@ -139,9 +139,14 @@ These semantics and rules will be outlined now.
NOOP
- This instruction does nothing.
-- If the verbose output from the BootROM is enabled, the BootROM will produce a
- letter on the Debug UART for each instruction it started processing. Here is
a
- mapping between the above instructions and the BootROM verbose output:
+ - An optional flags lines can be one of the following:
+
+ DISPLAYPROGRESS
+ - Enable boot progress output form the BootROM.
+
+- If the boot progress output from the BootROM is enabled, the BootROM will
+ produce a letter on the Debug UART for each instruction it started
processing.
+ Here is a mapping between the above instructions and the BootROM output:
H -- SB Image header loaded
T -- TAG instruction
diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 81c7f2d..ab18041 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -125,7 +125,7 @@ struct sb_image_ctx {
unsigned intin_section:1;
unsigned intin_dcd:1;
/* Image configuration */
- unsigned intverbose_boot:1;
+ unsigned intdisplay_progress:1;
unsigned intsilent_dump:1;
char*input_filename;
char*output_filename;
@@ -1308,8 +1308,7 @@ static int sb_prefill_image_header(struct sb_image_ctx
*ictx)
sizeof(struct sb_sections_header) / SB_BLOCK_SIZE;
hdr-timestamp_us = sb_get_timestamp() * 100;
- /* FIXME -- add proper config option */
- hdr-flags = ictx-verbose_boot ? SB_IMAGE_FLAG_VERBOSE : 0,
+ hdr-flags = ictx-display_progress ? SB_IMAGE_FLAG_DISPLAY_PROGRESS :
0;
/* FIXME -- We support only default key */
hdr-key_count = 1;
@@ -1427,6 +1426,12 @@ static int sb_parse_line(struct sb_image_ctx *ictx,
struct sb_cmd_list *cmd)
}
cmd-cmd = rptr;
+
+ /* set DISPLAY_PROGRESS flag */
+ if (!strcmp(tok, DISPLAYPROGRESS)) {
+ ictx-display_progress = 1;
+ return 0;
+ }
/* DCD */
if (!strcmp(tok, DCD)) {
@@ -1681,10 +1686,10 @@ static int sb_verify_image_header(struct sb_image_ctx
*ictx,
ntohs(hdr-component_version.minor),
ntohs(hdr-component_version.revision));
- if
Re: [U-Boot] [PATCH 9/9] ARM: sunxi: Add Ippo-q8h-v5 A23 tablet board defconfig
On Sun, Oct 12, 2014 at 12:17 AM, Ian Campbell i...@hellion.org.uk wrote: On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: Ippo q8h is a series of A23 tablet boards. This defconfig is for v5 of these boards, though for u-boot purposes they are mostly the same. Any differences worth mentioning? AFAIK, the boards have different wifi modules, which u-boot doesn't use anyway. See: http://linux-sunxi.org/Ippo_q8h BTW, this says The port is then used by the OpenRISC core to dump debug messages. Whether this port can be used by the primary system is still unknown. but your previous patches suggest this is now known? Updated. This was written before I started mainline kernel work. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk Thanks. --- board/sunxi/MAINTAINERS| 5 + configs/Ippo_q8h_defconfig | 4 2 files changed, 9 insertions(+) create mode 100644 configs/Ippo_q8h_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index 7afe45e..febd126 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -50,3 +50,8 @@ COLOMBUS BOARD M: Maxime Ripard maxime.rip...@free-electrons.com S: Maintained F: configs/Colombus_defconfig + +IPPO-Q8H-V5 BOARD +M: CHen-Yu Tsai w...@csie.org +S: Maintained +F: configs/Ippo_q8h_v5_defconfig diff --git a/configs/Ippo_q8h_defconfig b/configs/Ippo_q8h_defconfig new file mode 100644 index 000..781f137 --- /dev/null +++ b/configs/Ippo_q8h_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=IPPO_Q8H_V5,CONS_INDEX=5 +CONFIG_ARM=y +CONFIG_TARGET_SUN8I=y +CONFIG_DEFAULT_DEVICE_TREE=sun8i-a23-ippo-q8h-v5.dtb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] ARM: sunxi: Allow specifying module in prcm apb0 init function
On Sun, Oct 12, 2014 at 12:13 AM, Ian Campbell i...@hellion.org.uk wrote:
On Sat, 2014-10-11 at 17:11 +0100, Ian Campbell wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The prcm apb0 controls multiple modules. Allow specifying which
modules to enable clocks and de-assert resets so the function
can be reused.
How come this isn't actually called on sun6i?
(naughty of me not to notice this when it was submitted!)
Is it going to be called by anything in this series? I have a feeling
this is a precursor for SPL which should have been left out of the sun6i
series, but oh well what's done is done.
This will be used by P2WI and PMIC stuff. (series WiP)
Without a caller it's hard to make a judgement call on parameters vs
#ifdef in the function, although my inclination would generally be
towards parameters, if there's just going to be an ifdef at the call
site instead it's not really buying us much.
I should have read the next patch more carefully before commenting...
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Ian Campbell i...@hellion.org.uk
Thanks.
---
arch/arm/cpu/armv7/sunxi/prcm.c| 12 +++-
arch/arm/include/asm/arch-sunxi/prcm.h | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/prcm.c
b/arch/arm/cpu/armv7/sunxi/prcm.c
index 7b3ee89..19b4938 100644
--- a/arch/arm/cpu/armv7/sunxi/prcm.c
+++ b/arch/arm/cpu/armv7/sunxi/prcm.c
@@ -21,13 +21,15 @@
#include asm/arch/prcm.h
#include asm/arch/sys_proto.h
-void prcm_init_apb0(void)
+/* APB0 clock gate and reset bit offsets are the same. */
Is this absolutely guaranteed?
+void prcm_apb0_enable(u32 flags)
{
struct sunxi_prcm_reg *prcm =
(struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
- setbits_le32(prcm-apb0_gate, PRCM_APB0_GATE_P2WI |
- PRCM_APB0_GATE_PIO);
- setbits_le32(prcm-apb0_reset, PRCM_APB0_RESET_P2WI |
- PRCM_APB0_RESET_PIO);
+ /* open the clock for module */
+ setbits_le32(prcm-apb0_gate, flags);
+
+ /* deassert reset for module */
+ setbits_le32(prcm-apb0_reset, flags);
}
diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h
b/arch/arm/include/asm/arch-sunxi/prcm.h
index 1b40f09..3d3bfa6 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -233,6 +233,6 @@ struct sunxi_prcm_reg {
u32 dram_tst; /* 0x190 */
};
-void prcm_init_apb0(void);
+void prcm_apb0_enable(u32 flags);
#endif /* __ASSEMBLY__ */
#endif /* _PRCM_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks
On Sun, Oct 12, 2014 at 12:05 AM, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
From: Hans de Goede hdego...@redhat.com
The A31, A23 and later SoCs have an extra pin controller, called CPUs_PIO
or R_PIO, which handles pin banks L and beyond.
Does it also have enough space for 9 banks? Since you overlay a struct
sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it.
Yes it does, as seen in the latest A31 manuals released by Allwinner.
SUNXI_GPIO_BANKS is now also confusingly named since it is really
number of banks on the first/original GPIO controller. Eventually
someone will use it as the actual total and be very sad.
I think it might be best if we retcon some distinct name onto the
original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and
SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have
SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing)
The latest manuals have CPUx-PORT and CPUs-PORT for the respective
chapters. I'm guessing x is for 0~3 cores, and s is for standby or
something.
Of course it's also confusing that Allwinner's sources use the R_
prefix for all hardware in that address range, while the datasheet
lists the GPIO function names as s_something.
We might want to make sure the naming is consistent with the kernel
as well. (+CC Maxime)
ChenYu
If we still need SUNXI_GPIO_BANKS after that then it would be the sum of
those two.
Signed-off-by: Hans de Goede hdego...@redhat.com
[w...@csie.org: expanded commit message]
[w...@csie.org: add pin bank M and expand comments]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/include/asm/arch-sunxi/gpio.h | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index b94ec4d..bbe815a 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -10,6 +10,7 @@
#define _SUNXI_GPIO_H
#include linux/types.h
+#include asm/arch/cpu.h
/*
* sunxi has 9 banks of gpio, they are:
@@ -29,6 +30,19 @@
#define SUNXI_GPIO_I 8
#define SUNXI_GPIO_BANKS 9
+/*
+ * sun6i/sun8i and later SoCs have an additional GPIO controller (R_PIO)
+ * at a different register offset.
+ *
+ * sun6i has 2 banks:
+ * PL0 - PL8 | PM0 - PM7
+ *
+ * sun8i has 1 bank:
+ * PL0 - PL11
+ */
+#define SUNXI_GPIO_L 9
+#define SUNXI_GPIO_M 10
+
struct sunxi_gpio {
u32 cfg[4];
u32 dat;
@@ -50,8 +64,9 @@ struct sunxi_gpio_reg {
struct sunxi_gpio_int gpio_int;
};
-#define BANK_TO_GPIO(bank) \
- ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank]
+#define BANK_TO_GPIO(bank) (((bank) SUNXI_GPIO_BANKS) ? \
+ ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank] : \
+ ((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)-gpio_bank[(bank) -
SUNXI_GPIO_BANKS])
#define GPIO_BANK(pin) ((pin) 5)
#define GPIO_NUM(pin)((pin) 0x1f)
@@ -75,6 +90,8 @@ struct sunxi_gpio_reg {
#define SUNXI_GPIO_G_NR 32
#define SUNXI_GPIO_H_NR 32
#define SUNXI_GPIO_I_NR 32
+#define SUNXI_GPIO_L_NR 32
+#define SUNXI_GPIO_M_NR 32
#define SUNXI_GPIO_NEXT(__gpio) \
((__gpio##_START) + (__gpio##_NR) + 0)
@@ -89,6 +106,8 @@ enum sunxi_gpio_number {
SUNXI_GPIO_G_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_F),
SUNXI_GPIO_H_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_G),
SUNXI_GPIO_I_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_H),
+ SUNXI_GPIO_L_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_I),
+ SUNXI_GPIO_M_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_L),
};
/* SUNXI GPIO number definitions */
@@ -101,6 +120,8 @@ enum sunxi_gpio_number {
#define SUNXI_GPG(_nr) (SUNXI_GPIO_G_START + (_nr))
#define SUNXI_GPH(_nr) (SUNXI_GPIO_H_START + (_nr))
#define SUNXI_GPI(_nr) (SUNXI_GPIO_I_START + (_nr))
+#define SUNXI_GPL(_nr) (SUNXI_GPIO_L_START + (_nr))
+#define SUNXI_GPM(_nr) (SUNXI_GPIO_M_START + (_nr))
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] sunxi: Add mmc card-detect functionality
Hi, On 10/11/2014 05:39 PM, Ian Campbell wrote: On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com I presume that adding GPIO support to SPL isn't a problem size wise? We do link time size checking and ./MAKEALL -s sunxi still works fine, so yes it is not a problem. --- board/sunxi/Kconfig| 26 ++ drivers/mmc/sunxi_mmc.c| 21 + include/configs/sunxi-common.h | 1 + 3 files changed, 48 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 622f7b4..497b093 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,4 +32,30 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically used in combination with a graphical console on HDMI). +config MMC0_CD_PIN +string Card detect pin for mmc0 +default +---help--- +Set the card detect pin for mmc0, leave empty to not use cd. sunxi_name_to_gpio() doesn't handle the empty string directly, but I think it will do the right thing (i.e. return -1) via a more or less convoluted path. Did you check this? Yes I checked, it will return -1 on the empty string. Assuming you have then: Acked-by: Ian Campbell i...@hellion.org.uk Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
Hi, On 10/11/2014 05:40 PM, Ian Campbell wrote: On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote: Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL check is not necessary with Kconfig, because only options explicitly marked as also being for the SPL get set during SPL builds. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 8 board/sunxi/board.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 497b093..cb4a881 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -32,6 +32,14 @@ config USB_KEYBOARD Say Y here to add support for using a USB keyboard (typically used in combination with a graphical console on HDMI). +config MMC_SUNXI_SLOT_EXTRA +int mmc extra slot number +default -1 +---help--- +sunxi builds always enable mmc0, some boards also have a sdcard slot +or emmc on mmc2 or mmc3. Setting this to 2 or 3 will enable support +for this. What happened to mmc1? When writing this I was under the assumption that nothing was actually using mmc1, I will fix the help text. Regardless: Acked-by: Ian Campbell i...@hellion.org.uk Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] New discussion proposal for u-boot summit: switch malloc to succeed or die model, as glib does
Hi All, Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches. Ian asked me to add error handling for mmc_create failing, which, if used properly, only ever fails if calloc fails. This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a die() / abort() inside the low level malloc routines when they fail. The reasoning is that if malloc fails, you're typically looking at a fatal error anyways, and this will allow removing error handling from a lot of higher level users, reducing code, and removing a lot of code paths which are in essence unused and as such also very much untested. I guess there may be some special cases where we don't want the malloc_or_die behavior I'm advocating for, for those we could introduce a malloc_unchecked function. Detlev any chance you could squeeze this into the schedule somewhere? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New discussion proposal for u-boot summit: switch malloc to succeed or die model, as glib does
Hi, On 10/12/2014 10:42 AM, Hans de Goede wrote: Hi All, Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches. Ian asked me to add error handling for mmc_create failing, which, if used properly, only ever fails if calloc fails. This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a die() / abort() inside the low level malloc routines when they fail. I remembered that I've already seen something like this in u-boot, so after some grepping around I've found that at least common/cli_hush.c already does this. It introduces a (private) xmalloc and xrealloc which have the malloc_or_die behavior. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] ARM: sunxi: Fix build break when CONFIG_MMC is not defined
Hi, On 10/11/2014 05:50 PM, Ian Campbell wrote: On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote: BOOT_TARGET_DEVICES includes MMC unconditionally. This breaks when CONFIG_CMD_MMC is not defined. Use a secondary macro to conditionally include it when CONFIG_MMC is enabled, as we do for CONFIG_AHCI. This is used when we want to use uart0 from port F, which conflicts with mmc0. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Ian Campbell i...@hellion.org.uk Hans, this made me think back to your Enable second sdcard slot found on some boards series -- do you not want to add mmc1 as a boot target device when MMC_SUNXI_SLOT_EXTRA is enabled? An interesting question. u-boot itself is always running of mmc 0, or loaded through FEL, but that does not mean that e.g. extlinux.conf + the kernel and dts could not be on mmc 1. So yes I guess we do want to add mmc 1 as boot target. First lets get Chen's patches + my existing second mmc slot set merged into u-boot-sunxi next, and then I'll do a patch on top of that. Regards, Hans --- include/configs/sunxi-common.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index a31656e..7571e0e 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -227,6 +227,12 @@ pxefile_addr_r=0x4320\0 \ ramdisk_addr_r=0x4330\0 +#ifdef CONFIG_MMC +#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) +#else +#define BOOT_TARGET_DEVICES_MMC(func) +#endif + #ifdef CONFIG_AHCI #define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) #else @@ -240,7 +246,7 @@ #endif #define BOOT_TARGET_DEVICES(func) \ -func(MMC, mmc, 0) \ +BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
Hi,
On 10/11/2014 05:43 PM, Ian Campbell wrote:
On Mon, 2014-10-06 at 19:57 +0200, Hans de Goede wrote:
@@ -108,11 +109,31 @@ static void mmc_pinmux_setup(int sdc)
int board_mmc_init(bd_t *bis)
{
+__maybe_unused struct mmc *mmc0, *mmc1;
+__maybe_unused char buf[512];
+
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
-sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+mmc0 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
-sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+mmc1 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+#endif
+
+#if CONFIG_MMC_SUNXI_SLOT == 0 CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
+/*
+ * Both mmc0 and mmc2 are bootable, figure out where we're booting
+ * from. Try mmc0 first, just like the brom does.
+ */
+if (mmc_getcd(mmc0) mmc_init(mmc0) == 0
If sunxi_mmx_init failed then mmc0 might be NULL here.
+mmc0-block_dev.block_read(0, 16, 1, buf) == 1) {
+buf[12] = 0;
+if (strcmp(buf[4], eGON.BT0) == 0)
+return 0;
+}
+
+/* no bootable card in mmc0, so we must be booting from mmc2, swap */
+mmc0-block_dev.dev = 1;
+mmc1-block_dev.dev = 0;
and mmc1 could be NULL here.
Hmm, this only happens when the calloc in mmc_create fails. I'll fix this in
v3, but I really believe that we should just switch u-boot over to the glib
malloc model of malloc should never fail.
Regards,
Hans
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] ARM: sunxi: Add basic A23 support
On Sun, 2014-10-12 at 10:43 +0800, Chen-Yu Tsai wrote:
On Sat, Oct 11, 2014 at 11:58 PM, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
The basic blocks of the A23 are similar to the A31 (sun6i). Re-use
sun6i code for initial clock, gpio, and uart setup.
Do I take it that sun8i is also in the same position wrt DRAM bring up
code not existing yet and there therefore being no SPL yet?
That is correct.
Please could you add a sentence to the commit message.
Apart from that: Acked-by: Ian Campbell i...@hellion.org.uk
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/Kconfig| 3 +++
arch/arm/cpu/armv7/sunxi/Makefile | 2 ++
arch/arm/cpu/armv7/sunxi/board.c| 3 ++-
arch/arm/cpu/armv7/sunxi/cpu_info.c | 2 ++
arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
board/sunxi/Kconfig | 9 -
include/configs/sun8i.h | 23 +++
7 files changed, 41 insertions(+), 3 deletions(-)
create mode 100644 include/configs/sun8i.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e3e7e78..cb691b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -450,6 +450,9 @@ config TARGET_SUN6I
config TARGET_SUN7I
bool Support sun7i
+config TARGET_SUN8I
+ bool Support sun8i
+
config TARGET_SNOWBALL
bool Support snowball
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 2a42dca..24f1dae 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -12,10 +12,12 @@ obj-y += board.o
obj-y+= clock.o
obj-y+= pinmux.o
obj-$(CONFIG_SUN6I) += prcm.o
+obj-$(CONFIG_SUN8I) += prcm.o
obj-$(CONFIG_SUN4I) += clock_sun4i.o
obj-$(CONFIG_SUN5I) += clock_sun4i.o
obj-$(CONFIG_SUN6I) += clock_sun6i.o
obj-$(CONFIG_SUN7I) += clock_sun4i.o
+obj-$(CONFIG_SUN8I) += clock_sun6i.o
ifndef CONFIG_SPL_BUILD
obj-y+= cpu_info.o
diff --git a/arch/arm/cpu/armv7/sunxi/board.c
b/arch/arm/cpu/armv7/sunxi/board.c
index 29d45b6..61c1ba9 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -100,7 +100,8 @@ void reset_cpu(ulong addr)
/* do some early init */
void s_init(void)
{
-#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || defined
CONFIG_SUN6I)
+#if !defined CONFIG_SPL_BUILD (defined CONFIG_SUN7I || \
+ defined CONFIG_SUN6I || defined CONFIG_SUN8I)
At some point we should refactor this to use a common Kconfig thing
(SUNXI_SMP etc) which the relevant targets select.
I agree. We can do this as we move further to Kconfig.
ChenYu
/* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
asm volatile(
mrc p15, 0, r0, c1, c0, 1\n
diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 40c4e13..4f2a09c 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -27,6 +27,8 @@ int print_cpuinfo(void)
puts(CPU: Allwinner A31 (SUN6I)\n);
#elif defined CONFIG_SUN7I
puts(CPU: Allwinner A20 (SUN7I)\n);
+#elif defined CONFIG_SUN8I
+ puts(CPU: Allwinner A23 (SUN8I)\n);
#else
#warning Please update cpu_info.c with correct CPU information
puts(CPU: SUNXI Family\n);
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 8f5d860..012c2af 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -15,7 +15,7 @@
#define CLK_GATE_CLOSE 0x0
/* clock control module regs definition */
-#ifdef CONFIG_SUN6I
+#if defined(CONFIG_SUN6I) || defined(CONFIG_SUN8I)
#include asm/arch/clock_sun6i.h
#else
#include asm/arch/clock_sun4i.h
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 05defac..16f6db4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -27,7 +27,14 @@ config SYS_CONFIG_NAME
endif
-if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
+if TARGET_SUN8I
+
+config SYS_CONFIG_NAME
+ default sun8i
+
+endif
+
+if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I ||
TARGET_SUN8I
config SYS_CPU
default armv7
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
new file mode 100644
index 000..1c1a7cd
--- /dev/null
+++ b/include/configs/sun8i.h
@@ -0,0 +1,23 @@
+/*
+ * (C) Copyright 2014 Chen-Yu Tsai w...@csie.org
+ *
+ * Configuration settings for the Allwinner A23 (sun8i) CPU
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*
+ * A23 specific configuration
+ */
+#define CONFIG_SUN8I /*
Re: [U-Boot] [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks
On Sun, 2014-10-12 at 16:23 +0800, Chen-Yu Tsai wrote:
On Sun, Oct 12, 2014 at 12:05 AM, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
From: Hans de Goede hdego...@redhat.com
The A31, A23 and later SoCs have an extra pin controller, called CPUs_PIO
or R_PIO, which handles pin banks L and beyond.
Does it also have enough space for 9 banks? Since you overlay a struct
sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it.
Yes it does, as seen in the latest A31 manuals released by Allwinner.
SUNXI_GPIO_BANKS is now also confusingly named since it is really
number of banks on the first/original GPIO controller. Eventually
someone will use it as the actual total and be very sad.
I think it might be best if we retcon some distinct name onto the
original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and
SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have
SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing)
The latest manuals have CPUx-PORT and CPUs-PORT for the respective
chapters. I'm guessing x is for 0~3 cores, and s is for standby or
something.
Of course it's also confusing that Allwinner's sources use the R_
prefix for all hardware in that address range, while the datasheet
lists the GPIO function names as s_something.
We might want to make sure the naming is consistent with the kernel
as well. (+CC Maxime)
Good idea, last thing we want to do is introduce yet another
standard ;-)
ChenYu
If we still need SUNXI_GPIO_BANKS after that then it would be the sum of
those two.
Signed-off-by: Hans de Goede hdego...@redhat.com
[w...@csie.org: expanded commit message]
[w...@csie.org: add pin bank M and expand comments]
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/include/asm/arch-sunxi/gpio.h | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index b94ec4d..bbe815a 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -10,6 +10,7 @@
#define _SUNXI_GPIO_H
#include linux/types.h
+#include asm/arch/cpu.h
/*
* sunxi has 9 banks of gpio, they are:
@@ -29,6 +30,19 @@
#define SUNXI_GPIO_I 8
#define SUNXI_GPIO_BANKS 9
+/*
+ * sun6i/sun8i and later SoCs have an additional GPIO controller (R_PIO)
+ * at a different register offset.
+ *
+ * sun6i has 2 banks:
+ * PL0 - PL8 | PM0 - PM7
+ *
+ * sun8i has 1 bank:
+ * PL0 - PL11
+ */
+#define SUNXI_GPIO_L 9
+#define SUNXI_GPIO_M 10
+
struct sunxi_gpio {
u32 cfg[4];
u32 dat;
@@ -50,8 +64,9 @@ struct sunxi_gpio_reg {
struct sunxi_gpio_int gpio_int;
};
-#define BANK_TO_GPIO(bank) \
- ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank]
+#define BANK_TO_GPIO(bank) (((bank) SUNXI_GPIO_BANKS) ? \
+ ((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)-gpio_bank[bank] : \
+ ((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)-gpio_bank[(bank) -
SUNXI_GPIO_BANKS])
#define GPIO_BANK(pin) ((pin) 5)
#define GPIO_NUM(pin)((pin) 0x1f)
@@ -75,6 +90,8 @@ struct sunxi_gpio_reg {
#define SUNXI_GPIO_G_NR 32
#define SUNXI_GPIO_H_NR 32
#define SUNXI_GPIO_I_NR 32
+#define SUNXI_GPIO_L_NR 32
+#define SUNXI_GPIO_M_NR 32
#define SUNXI_GPIO_NEXT(__gpio) \
((__gpio##_START) + (__gpio##_NR) + 0)
@@ -89,6 +106,8 @@ enum sunxi_gpio_number {
SUNXI_GPIO_G_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_F),
SUNXI_GPIO_H_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_G),
SUNXI_GPIO_I_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_H),
+ SUNXI_GPIO_L_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_I),
+ SUNXI_GPIO_M_START = SUNXI_GPIO_NEXT(SUNXI_GPIO_L),
};
/* SUNXI GPIO number definitions */
@@ -101,6 +120,8 @@ enum sunxi_gpio_number {
#define SUNXI_GPG(_nr) (SUNXI_GPIO_G_START + (_nr))
#define SUNXI_GPH(_nr) (SUNXI_GPIO_H_START + (_nr))
#define SUNXI_GPI(_nr) (SUNXI_GPIO_I_START + (_nr))
+#define SUNXI_GPL(_nr) (SUNXI_GPIO_L_START + (_nr))
+#define SUNXI_GPM(_nr) (SUNXI_GPIO_M_START + (_nr))
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH resend] kconfig: Fix compiler warning in menu.c
This fixes the following compiler warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
jump-offset = strlen(r-s);
^
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c:551:19: note: ‘jump’ was declared here
struct jump_key *jump;
Signed-off-by: Hans de Goede hdego...@redhat.com
---
scripts/kconfig/menu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index a26cc5d..584e0fc 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -548,7 +548,7 @@ static void get_prompt_str(struct gstr *r, struct property
*prop,
{
int i, j;
struct menu *submenu[8], *menu, *location = NULL;
- struct jump_key *jump;
+ struct jump_key *jump = NULL;
str_printf(r, _(Prompt: %s\n), _(prop-text));
menu = prop-menu-parent;
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH resend] kconfig: Fix compiler warning in menu.c
Hi, This one seems to have fallen through the cracks. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] New discussion proposal for u-boot summit: switch malloc to succeed or die model, as glib does
Hi Hans, Sorry for the poor timing in bringing this up, but this just came up when discussing the review of some sunxi patches. Ian asked me to add error handling for mmc_create failing, which, if used properly, only ever fails if calloc fails. This made me thinking that we should switch u-boot to the glib memory alloc failure handling model, which is put a die() / abort() inside the low level malloc routines when they fail. The reasoning is that if malloc fails, you're typically looking at a fatal error anyways, and this will allow removing error handling from a lot of higher level users, reducing code, and removing a lot of code paths which are in essence unused and as such also very much untested. I guess there may be some special cases where we don't want the malloc_or_die behavior I'm advocating for, for those we could introduce a malloc_unchecked function. Detlev any chance you could squeeze this into the schedule somewhere? I'll note it for the list of things to discuss in the discussion round in the evening. Cheers Detlev -- (let ((s bottles of beer on the wall)) ((lambda (f) (f f 99)) (lambda (f i) (or (= i 0) (format #t ~a ~a - take one down pass it around ~a ~a\n i s (- i 1) s) (f f (- i 1)) -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] novena: Fix ethernet PHY reset sequence
From: Nikolay Dimitrov picmas...@mail.bg
This patch fixes conflict between PHY pins becoming outputs after reset and
imx6 still driving the pins. It also fixes the reset timing as recommended by
the PHY datasheet.
Signed-off-by: Nikolay Dimitrov picmas...@mail.bg
Cc: Stefano Babic sba...@denx.de
Cc: Sean Cross x...@kosagi.com
Cc: Marek Vasut ma...@denx.de
---
board/kosagi/novena/novena.c |3 --
board/kosagi/novena/novena_spl.c | 64 +++---
2 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
index 2361a3c..6add9e5 100644
--- a/board/kosagi/novena/novena.c
+++ b/board/kosagi/novena/novena.c
@@ -237,9 +237,6 @@ int board_early_init_f(void)
setup_display();
#endif
- /* Bring Ethernet PHY out of reset. */
- gpio_set_value(IMX_GPIO_NR(3, 23), 1);
-
return 0;
}
diff --git a/board/kosagi/novena/novena_spl.c b/board/kosagi/novena/novena_spl.c
index a8389d9..c4155dd 100644
--- a/board/kosagi/novena/novena_spl.c
+++ b/board/kosagi/novena/novena_spl.c
@@ -41,6 +41,10 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+#define ENET_PHY_CFG_PAD_CTRL \
+ (PAD_CTL_PKE | PAD_CTL_PUE |\
+ PAD_CTL_PUS_22K_UP | PAD_CTL_HYS)
+
#define RGMII_PAD_CTRL \
(PAD_CTL_PKE | PAD_CTL_PUE |\
PAD_CTL_PUS_100K_UP | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
@@ -98,18 +102,20 @@ static iomux_v3_cfg_t enet_pads1[] = {
MX6_PAD_RGMII_TD3__RGMII_TD3| MUX_PAD_CTRL(RGMII_PAD_CTRL),
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(RGMII_PAD_CTRL),
MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
- /* pin 35 - 1 (PHY_AD2) on reset */
- MX6_PAD_RGMII_RXC__GPIO6_IO30 | MUX_PAD_CTRL(NO_PAD_CTRL),
- /* pin 32 - 1 - (MODE0) all */
- MX6_PAD_RGMII_RD0__GPIO6_IO25 | MUX_PAD_CTRL(NO_PAD_CTRL),
- /* pin 31 - 1 - (MODE1) all */
- MX6_PAD_RGMII_RD1__GPIO6_IO27 | MUX_PAD_CTRL(NO_PAD_CTRL),
- /* pin 28 - 1 - (MODE2) all */
- MX6_PAD_RGMII_RD2__GPIO6_IO28 | MUX_PAD_CTRL(NO_PAD_CTRL),
- /* pin 27 - 1 - (MODE3) all */
- MX6_PAD_RGMII_RD3__GPIO6_IO29 | MUX_PAD_CTRL(NO_PAD_CTRL),
- /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */
- MX6_PAD_RGMII_RX_CTL__GPIO6_IO24| MUX_PAD_CTRL(NO_PAD_CTRL),
+
+ /* pin 35, PHY_AD2 */
+ MX6_PAD_RGMII_RXC__GPIO6_IO30 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+ /* pin 32, MODE0 */
+ MX6_PAD_RGMII_RD0__GPIO6_IO25 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+ /* pin 31, MODE1 */
+ MX6_PAD_RGMII_RD1__GPIO6_IO27 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+ /* pin 28, MODE2 */
+ MX6_PAD_RGMII_RD2__GPIO6_IO28 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+ /* pin 27, MODE3 */
+ MX6_PAD_RGMII_RD3__GPIO6_IO29 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+ /* pin 33, CLK125_EN */
+ MX6_PAD_RGMII_RX_CTL__GPIO6_IO24 | MUX_PAD_CTRL(ENET_PHY_CFG_PAD_CTRL),
+
/* pin 42 PHY nRST */
MX6_PAD_EIM_D23__GPIO3_IO23 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
@@ -127,15 +133,37 @@ static void novena_spl_setup_iomux_enet(void)
{
imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
+ /* Assert Ethernet PHY nRST */
gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
- gpio_direction_output(IMX_GPIO_NR(6, 30), 1);
- gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
- gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
- gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
- gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
- gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
+ /*
+* Use imx6 internal pull-ups to drive PHY mode pins during PHY reset
+* de-assertion. The intention is to use weak signal drivers (pull-ups)
+* to prevent the conflict between PHY pins becoming outputs after
+* reset and imx6 still driving the pins. The issue is described in PHY
+* datasheet, p.14
+*/
+ gpio_direction_input(IMX_GPIO_NR(6, 30)); /* PHY_AD2 = 1 */
+ gpio_direction_input(IMX_GPIO_NR(6, 25)); /* MODE0 = 1 */
+ gpio_direction_input(IMX_GPIO_NR(6, 27)); /* MODE1 = 1 */
+ gpio_direction_input(IMX_GPIO_NR(6, 28)); /* MODE2 = 1 */
+ gpio_direction_input(IMX_GPIO_NR(6, 29)); /* MODE3 = 1 */
+ gpio_direction_input(IMX_GPIO_NR(6, 24)); /* CLK125_EN = 1 */
+
+ /* Following reset timing (p.53, fig.8 from the PHY datasheet) */
+ mdelay(10);
+
+ /* De-assert Ethernet PHY nRST */
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1);
+
+ /* PHY is now configured, connect FEC to the
Re: [U-Boot] Discussion topics / issues
Hello Wolfgang / Albert / others, On 10-10-14 16:04, Jeroen Hofstee wrote: Hello Wolfgang, On 10-10-14 14:22, Wolfgang Denk wrote: It does not mention puts() vs. printf(), if it is indeed meant to be u-boot policy. This is not just U-Boot philosophy, but something that I would consider a matter of course when writing code - using the appropriate tools for the task at hand. If all you want to do is sendout a constant string to the utput device, there is no need to invoke a function that provides fancy formatting options. Don't we always try to use the smallest, most efficient tool that is suited for a task? calling printf(%s\n, string) gets translated into puts by the compiler. There should be no difference in the binary. mumbles: while this is true in general it won't hold for u-boot since -ffreestanding disables such rewrites and u-boot is compiled with that flag. On the bright side, perhaps I educated some people a bit that they are wasting time rewriting such lines in normal, hosted applications. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] genboardscfg.py: use Python2 from default path
Hello Wolfgang, On 30-09-14 10:17, Wolfgang Denk wrote: Instead of searching for Python2 in $PATH, use the one installed by the system (i. e. /usr/bin/python2). This prevents failures like this: - ./MAKEALL m53evk Traceback (most recent call last): File tools/genboardscfg.py, line 19, in module import fnmatch ImportError: No module named fnmatch Failed to generate boards.cfg This happens for example with all but the most recent versions of Yocto based tool chains (inclusing all currently existing versions of the ELDK), which provide a python2 binary in SYSROOT/usr/bin/python2, but do not include the fnmatch module. By using the system installed Python interpreter, the user is able to install any missing modules himself, without need to patch and rebuild the whole tool chain. Well lets start with, is this an issue at all? I never run MAKEALL from oe as it taints my environment. Thanks to Masahiro, deployment should not depend on python at all. Developers can install the required python version themselves, even if they don't have root priviliges, since env can pick it up. Furthermore the tool chains are there to provide the needed tools, so to insist on using the host version is exactly the opposite of what they want to achieve. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] novena: Fix ethernet PHY reset sequence
On Sun, Oct 12, 2014 at 7:47 AM, picmas...@mail.bg wrote: From: Nikolay Dimitrov picmas...@mail.bg This patch fixes conflict between PHY pins becoming outputs after reset and imx6 still driving the pins. It also fixes the reset timing as recommended by the PHY datasheet. Signed-off-by: Nikolay Dimitrov picmas...@mail.bg Cc: Stefano Babic sba...@denx.de Cc: Sean Cross x...@kosagi.com Cc: Marek Vasut ma...@denx.de Reviewed-by: Fabio Estevam fabio.este...@freescale.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] kconfig: Fix compiler warning in menu.c
Hello Hans, On 12-10-14 12:25, Hans de Goede wrote: Hi, This one seems to have fallen through the cracks. Regards, Hans (for U-boot) nope, you replace an innocent warning (_might_ be) with bad code, without any comment it is just because gcc failed to recognize it is fine. Nor did you respond to the suggestion if it helps gcc to recognize that if the two booleans are merged into a single one. [or even split it in an if () if ()]. With this patch you prevent any serious warning in case the variable is actually used but not initialized, which is even worse if you ask me. Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/6] sunxi: Enable second sdcard slot found on some boards
Hi Ian, Here is v3 of my second sdcard slot patch-set. Changes since v2: - Rebased on top of latest u-boot-sunxi-next - Fixed Kconfig help text for : sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option to also mention mmc1 - Added checks for sunxi_mmc_init failing to: sunxi: When we've both mmc0 and mmc2, detect from which one we're booting - Added a 6th patch with my version of the Kconfig unification, to avoid you needing to rebase yours. I believe this patch is ready to go upstream now, so if I can have your Acked-by for patches 3 and 6, then I'll push this to next, or you can push this to next yourself. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code
Unify the sunxi Kconfig code, instead of having seperate code blocks for each of sun4i, sun5i and sun7i. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 32 +--- 1 file changed, 5 insertions(+), 27 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 552fce8..4ac562c 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -1,33 +1,11 @@ -if TARGET_SUN4I - -config SYS_CONFIG_NAME - default sun4i - -endif - -if TARGET_SUN5I - -config SYS_CONFIG_NAME - default sun5i - -endif - -if TARGET_SUN6I +if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I config SYS_CONFIG_NAME string - default sun6i - -endif - -if TARGET_SUN7I - -config SYS_CONFIG_NAME - default sun7i - -endif - -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I + default sun4i if TARGET_SUN4I + default sun5i if TARGET_SUN5I + default sun6i if TARGET_SUN5I + default sun7i if TARGET_SUN7I config SYS_CPU default armv7 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/6] sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option
Note we also drop the SPL check for initializing the 2nd mmc slot, the SPL
check is not necessary with Kconfig, because only options explicitly marked
as also being for the SPL get set during SPL builds.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Ian Campbell i...@hellion.org.uk
---
board/sunxi/Kconfig | 8
board/sunxi/board.c | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 63188dd..552fce8 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -67,4 +67,12 @@ config MMC3_CD_PIN
---help---
See MMC0_CD_PIN help text.
+config MMC_SUNXI_SLOT_EXTRA
+ int mmc extra slot number
+ default -1
+ ---help---
+ sunxi builds always enable mmc0, some boards also have a second sdcard
+ slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
+ support for this.
+
endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2179e23..cfe22b6 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -106,7 +106,7 @@ int board_mmc_init(bd_t *bis)
{
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
-#if !defined (CONFIG_SPL_BUILD) defined (CONFIG_MMC_SUNXI_SLOT_EXTRA)
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
#endif
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/6] sunxi: Enable second sdcard slot found on some boards
Enable the second sdcard slot found on some boards. Note that we do not set CONFIG_MMC_SUNXI_SLOT_EXTRA for the SPL, as having it there is not useful, Except for on the Mele-M3 where the second sdcard is an eMMC, from which the device can also boot, and there we want to have both in the SPL, so that a single u-boot binary can both from both. So for the M3 we do prefix the defconfig setting with the special +S: syntax so that it applies to the SPL too. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- configs/A10s-OLinuXino-M_defconfig| 3 +++ configs/A20-OLinuXino_MICRO_defconfig | 3 +++ configs/Mele_M3_defconfig | 2 ++ 3 files changed, 8 insertions(+) diff --git a/configs/A10s-OLinuXino-M_defconfig b/configs/A10s-OLinuXino-M_defconfig index a578c06..2aad834 100644 --- a/configs/A10s-OLinuXino-M_defconfig +++ b/configs/A10s-OLinuXino-M_defconfig @@ -1,5 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A10S_OLINUXINO_M,AXP152_POWER,SUNXI_EMAC,USB_EHCI,SUNXI_USB_VBUS0_GPIO=SUNXI_GPB(10) CONFIG_FDTFILE=sun5i-a10s-olinuxino-micro.dtb +CONFIG_MMC_SUNXI_SLOT_EXTRA=1 ++S:CONFIG_MMC0_CD_PIN=PG1 ++S:CONFIG_MMC1_CD_PIN=PG13 +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN5I=y diff --git a/configs/A20-OLinuXino_MICRO_defconfig b/configs/A20-OLinuXino_MICRO_defconfig index 20a947c..0e0a7de 100644 --- a/configs/A20-OLinuXino_MICRO_defconfig +++ b/configs/A20-OLinuXino_MICRO_defconfig @@ -1,5 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=A20_OLINUXINO_M,AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI CONFIG_FDTFILE=sun7i-a20-olinuxino-micro.dtb +CONFIG_MMC_SUNXI_SLOT_EXTRA=3 ++S:CONFIG_MMC0_CD_PIN=PH1 ++S:CONFIG_MMC3_CD_PIN=PH11 +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig index 645b236..a043ad2 100644 --- a/configs/Mele_M3_defconfig +++ b/configs/Mele_M3_defconfig @@ -1,5 +1,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=MELE_M3,AXP209_POWER,SUNXI_GMAC,USB_EHCI CONFIG_FDTFILE=sun7i-a20-m3.dtb ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 ++S:CONFIG_MMC0_CD_PIN=PH1 +S:CONFIG_ARM=y +S:CONFIG_TARGET_SUN7I=y -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're
booting, and make that one mmc dev 0 so that a single u-boot binary can
be used for both the onboard eMMC and for external sdcards.
When we're booting from mmc2, we make it dev 0 because that is where the SPL
will load the tertiary payload (the actual u-boot binary in our case) from,
see: common/spl/spl_mmc.c, which has dev 0 hardcoded everywhere.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
board/sunxi/board.c | 30 --
drivers/mmc/sunxi_mmc.c | 7 ++-
3 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 6a31184..70d7875 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -123,5 +123,5 @@ struct sunxi_mmc {
#define SUNXI_MMC_IDIE_TXIRQ (0x1 0)
#define SUNXI_MMC_IDIE_RXIRQ (0x1 1)
-int sunxi_mmc_init(int sdc_no);
+struct mmc *sunxi_mmc_init(int sdc_no);
#endif /* _SUNXI_MMC_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index cfe22b6..f310e8d 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -12,6 +12,7 @@
*/
#include common.h
+#include mmc.h
#ifdef CONFIG_AXP152_POWER
#include axp152.h
#endif
@@ -104,11 +105,36 @@ static void mmc_pinmux_setup(int sdc)
int board_mmc_init(bd_t *bis)
{
+ __maybe_unused struct mmc *mmc0, *mmc1;
+ __maybe_unused char buf[512];
+
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT);
- sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+ mmc0 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT);
+ if (!mmc0)
+ return -1;
+
#if CONFIG_MMC_SUNXI_SLOT_EXTRA != -1
mmc_pinmux_setup(CONFIG_MMC_SUNXI_SLOT_EXTRA);
- sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+ mmc1 = sunxi_mmc_init(CONFIG_MMC_SUNXI_SLOT_EXTRA);
+ if (!mmc1)
+ return -1;
+#endif
+
+#if CONFIG_MMC_SUNXI_SLOT == 0 CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
+ /*
+* Both mmc0 and mmc2 are bootable, figure out where we're booting
+* from. Try mmc0 first, just like the brom does.
+*/
+ if (mmc_getcd(mmc0) mmc_init(mmc0) == 0
+ mmc0-block_dev.block_read(0, 16, 1, buf) == 1) {
+ buf[12] = 0;
+ if (strcmp(buf[4], eGON.BT0) == 0)
+ return 0;
+ }
+
+ /* no bootable card in mmc0, so we must be booting from mmc2, swap */
+ mmc0-block_dev.dev = 1;
+ mmc1-block_dev.dev = 0;
#endif
return 0;
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b47376a..d3b1039 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -373,7 +373,7 @@ static const struct mmc_ops sunxi_mmc_ops = {
.getcd = sunxi_mmc_getcd,
};
-int sunxi_mmc_init(int sdc_no)
+struct mmc *sunxi_mmc_init(int sdc_no)
{
struct mmc_config *cfg = mmc_host[sdc_no].cfg;
@@ -396,8 +396,5 @@ int sunxi_mmc_init(int sdc_no)
mmc_resource_init(sdc_no);
mmc_clk_io_on(sdc_no);
- if (mmc_create(cfg, mmc_host[sdc_no]) == NULL)
- return -1;
-
- return 0;
+ return mmc_create(cfg, mmc_host[sdc_no]);
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/6] sunxi: Add mmc card-detect functionality
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Ian Campbell i...@hellion.org.uk
---
board/sunxi/Kconfig| 26 ++
drivers/mmc/sunxi_mmc.c| 21 +
include/configs/sunxi-common.h | 1 +
3 files changed, 48 insertions(+)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 05defac..63188dd 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -41,4 +41,30 @@ config SYS_SOC
config FDTFILE
string Default fdtfile env setting for this board
+config MMC0_CD_PIN
+ string Card detect pin for mmc0
+ default
+ ---help---
+ Set the card detect pin for mmc0, leave empty to not use cd. This
+ takes a string in the format understood by sunxi_name_to_gpio, e.g.
+ PH1 for pin 1 of port H.
+
+config MMC1_CD_PIN
+ string Card detect pin for mmc1
+ default
+ ---help---
+ See MMC0_CD_PIN help text.
+
+config MMC2_CD_PIN
+ string Card detect pin for mmc2
+ default
+ ---help---
+ See MMC0_CD_PIN help text.
+
+config MMC3_CD_PIN
+ string Card detect pin for mmc3
+ default
+ ---help---
+ See MMC0_CD_PIN help text.
+
endif
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 8f4b50b..b47376a 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -14,7 +14,9 @@
#include asm/io.h
#include asm/arch/clock.h
#include asm/arch/cpu.h
+#include asm/arch/gpio.h
#include asm/arch/mmc.h
+#include asm-generic/gpio.h
struct sunxi_mmc_host {
unsigned mmc_no;
@@ -346,10 +348,29 @@ out:
return error;
}
+static int sunxi_mmc_getcd(struct mmc *mmc)
+{
+ struct sunxi_mmc_host *mmchost = mmc-priv;
+ int cd_pin = -1;
+
+ switch (mmchost-mmc_no) {
+ case 0: cd_pin = sunxi_name_to_gpio(CONFIG_MMC0_CD_PIN); break;
+ case 1: cd_pin = sunxi_name_to_gpio(CONFIG_MMC1_CD_PIN); break;
+ case 2: cd_pin = sunxi_name_to_gpio(CONFIG_MMC2_CD_PIN); break;
+ case 3: cd_pin = sunxi_name_to_gpio(CONFIG_MMC3_CD_PIN); break;
+ }
+
+ if (cd_pin == -1)
+ return 1;
+
+ return !gpio_direction_input(cd_pin);
+}
+
static const struct mmc_ops sunxi_mmc_ops = {
.send_cmd = mmc_send_cmd,
.set_ios= mmc_set_ios,
.init = mmc_core_init,
+ .getcd = sunxi_mmc_getcd,
};
int sunxi_mmc_init(int sdc_no)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index a31656e..24bd22a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -183,6 +183,7 @@
/* GPIO */
#define CONFIG_SUNXI_GPIO
+#define CONFIG_SPL_GPIO_SUPPORT
#define CONFIG_CMD_GPIO
/* Ethernet support */
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/6] sunxi: Use PG3 - PG8 as io-pins for mmc1
None of the known sunxi devices actually use mmc1 routed through PH, where
as some devices do actually use mmc1 routed through PG, so change the routing
of mmc1 to PG. If in the future we encounter devices with mmc1 routed through
PH, we will need to change things to be a bit more flexible.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
board/sunxi/board.c| 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index ba7e69b..59122db 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -117,6 +117,8 @@ enum sunxi_gpio_number {
#define SUN5I_GPB19_UART0_TX 2
#define SUN5I_GPB20_UART0_RX 2
+#define SUN5I_GPG3_SDC12
+
#define SUN5I_GPG3_UART1_TX4
#define SUN5I_GPG4_UART1_RX4
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index f310e8d..03890c8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -71,9 +71,9 @@ static void mmc_pinmux_setup(int sdc)
break;
case 1:
- /* CMD-PH22, CLK-PH23, D0~D3-PH24~27 : 5 */
- for (pin = SUNXI_GPH(22); pin = SUNXI_GPH(27); pin++) {
- sunxi_gpio_set_cfgpin(pin, SUN4I_GPH22_SDC1);
+ /* CMD-PG3, CLK-PG4, D0~D3-PG5-8 */
+ for (pin = SUNXI_GPG(3); pin = SUNXI_GPG(8); pin++) {
+ sunxi_gpio_set_cfgpin(pin, SUN5I_GPG3_SDC1);
sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(pin, 2);
}
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Broken target
The 'tools-only' target seems to be broken. In a clean tree (no previous build) running: $: make tools-only fails with: CHK include/config/uboot.release /bin/sh: 1: cannot open include/config/auto.conf: No such file Makefile:1049: recipe for target 'include/config/uboot.release' failed make: *** [include/config/uboot.release] Error 2 Any idea about the root cause? it is a regression as 2014.07 works fine in this case. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] sunxi: When we've both mmc0 and mmc2, detect from which one we're booting
On Sun, 2014-10-12 at 20:07 +0200, Hans de Goede wrote: sunxi SOCs can boot from both mmc0 and mmc2, detect from which one we're booting, and make that one mmc dev 0 so that a single u-boot binary can be used for both the onboard eMMC and for external sdcards. When we're booting from mmc2, we make it dev 0 because that is where the SPL will load the tertiary payload (the actual u-boot binary in our case) from, see: common/spl/spl_mmc.c, which has dev 0 hardcoded everywhere. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code
On Sun, 2014-10-12 at 20:07 +0200, Hans de Goede wrote: Unify the sunxi Kconfig code, instead of having seperate code blocks for separate each of sun4i, sun5i and sun7i. Signed-off-by: Hans de Goede hdego...@redhat.com Looks pretty familiar ;-) Acked-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/Kconfig | 32 +--- 1 file changed, 5 insertions(+), 27 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 552fce8..4ac562c 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -1,33 +1,11 @@ -if TARGET_SUN4I - -config SYS_CONFIG_NAME - default sun4i - -endif - -if TARGET_SUN5I - -config SYS_CONFIG_NAME - default sun5i - -endif - -if TARGET_SUN6I +if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I config SYS_CONFIG_NAME string - default sun6i - -endif - -if TARGET_SUN7I - -config SYS_CONFIG_NAME - default sun7i - -endif - -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I + default sun4i if TARGET_SUN4I + default sun5i if TARGET_SUN5I + default sun6i if TARGET_SUN5I + default sun7i if TARGET_SUN7I config SYS_CPU default armv7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] sunxi: Enable second sdcard slot found on some boards
On Sun, 2014-10-12 at 20:07 +0200, Hans de Goede wrote: Hi Ian, Here is v3 of my second sdcard slot patch-set. Changes since v2: - Rebased on top of latest u-boot-sunxi-next - Fixed Kconfig help text for : sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option to also mention mmc1 - Added checks for sunxi_mmc_init failing to: sunxi: When we've both mmc0 and mmc2, detect from which one we're booting - Added a 6th patch with my version of the Kconfig unification, to avoid you needing to rebase yours. I believe this patch is ready to go upstream now, so if I can have your Acked-by for patches 3 and 6, then I'll push this to next, or you can push this to next yourself. All Acked. I'm not going to commit tonight and I'm on trains all day tomorrow (heading to Düsseldorf), unless I hear otherwise I'll assume you are doing it. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] sunxi: Enable second sdcard slot found on some boards
Hi, On 10/12/2014 11:19 PM, Ian Campbell wrote: On Sun, 2014-10-12 at 20:07 +0200, Hans de Goede wrote: Hi Ian, Here is v3 of my second sdcard slot patch-set. Changes since v2: - Rebased on top of latest u-boot-sunxi-next - Fixed Kconfig help text for : sunxi: Turn MMC_SUNXI_SLOT_EXTRA into a proper Kconfig option to also mention mmc1 - Added checks for sunxi_mmc_init failing to: sunxi: When we've both mmc0 and mmc2, detect from which one we're booting - Added a 6th patch with my version of the Kconfig unification, to avoid you needing to rebase yours. I believe this patch is ready to go upstream now, so if I can have your Acked-by for patches 3 and 6, then I'll push this to next, or you can push this to next yourself. All Acked. I'm not going to commit tonight and I'm on trains all day tomorrow (heading to Düsseldorf), unless I hear otherwise I'll assume you are doing it. Done. And good to hear that you're heading over to Dusseldorf too. I'll be at the u-boot mini-summit the entire day today (currently in the train towards Dusseldorf). We definitely should get together, even if just to say hi :) Maybe I'll see you at the u-boot mini-summit ? If you cannot make it, maybe you can make the u-boot dinner tonight ? : http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014 Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH resend] kconfig: Fix compiler warning in menu.c
Hi Jeroen, On 12 October 2014 10:13, Jeroen Hofstee jer...@myspectrum.nl wrote: Hello Hans, On 12-10-14 12:25, Hans de Goede wrote: Hi, This one seems to have fallen through the cracks. Regards, Hans (for U-boot) nope, you replace an innocent warning (_might_ be) with bad code, without any comment it is just because gcc failed to recognize it is fine. Nor did you respond to the suggestion if it helps gcc to recognize that if the two booleans are merged into a single one. [or even split it in an if () if ()]. With this patch you prevent any serious warning in case the variable is actually used but not initialized, which is even worse if you ask me. That is a pretty acerbic tone to take on the U-Boot list at least. Are you two drinking buddies or something? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 08/12] 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 --- include/configs/sandbox.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 2fd2c64..c5b46ac 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -110,6 +110,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.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 03/12] 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
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-uclass.c | 177 +++
include/config_fallbacks.h | 6 ++
include/dm/uclass-id.h | 1 +
include/i2c.h | 252 +
5 files changed, 437 insertions(+)
create mode 100644 drivers/i2c/i2c-uclass.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 416ea4f..2ee468d 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_BFIN_TWI_I2C) += bfin-twi_i2c.o
obj-$(CONFIG_DW_I2C) += designware_i2c.o
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
new file mode 100644
index 000..6bdce8c
--- /dev/null
+++ b/drivers/i2c/i2c-uclass.c
@@ -0,0 +1,177 @@
+/*
+ * 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 dm/device-internal.h
+#include dm/root.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int i2c_read(struct udevice *dev, uint addr, 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);
+
+ if (!ops-read)
+ return -ENOSYS;
+
+ return ops-read(bus, chip-chip_addr, addr, chip-addr_len, buffer,
+len);
+}
+
+int i2c_write(struct udevice *dev, uint addr, 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);
+
+ if (!ops-write)
+ return -ENOSYS;
+
+ return ops-write(bus, chip-chip_addr, addr, chip-addr_len, buffer,
+ len);
+}
+
+int i2c_get_chip(struct udevice *bus, uint chip_addr, struct udevice **devp)
+{
+ struct udevice *dev;
+
+ for (device_find_first_child(bus, dev); dev;
+ device_find_next_child(dev)) {
+ struct dm_i2c_chip store;
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ int ret;
+
+ if (!chip) {
+ chip = store;
+ i2c_chip_ofdata_to_platdata(gd-fdt_blob,
+ dev-of_offset, chip);
+ }
+ if (chip-chip_addr == chip_addr) {
+ ret = device_probe(dev);
+ if (ret)
+ return ret;
+ *devp = dev;
+ return 0;
+ }
+ }
+
+ return -ENODEV;
+}
+
+int i2c_probe(struct udevice *bus, uint chip)
+{
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct udevice *dev;
+ int ret;
+
+ if (!ops-probe)
+ return -ENODEV;
+
+ /* First probe that chip */
+ ret = ops-probe(bus, chip);
+ if (ret)
+ return ret;
+
+ /* The cihp was found, see if we have a driver, and probe it */
+ return i2c_get_chip(bus, chip, dev);
+
+ /* No driver. TODO create a dummy one */
+}
+
+int i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
+{
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ struct dm_i2c_bus *i2c = bus-uclass_priv;
+ int ret;
+
+ if (ops-set_bus_speed) {
+ ret = ops-set_bus_speed(bus, speed);
+ if (ret)
+ return ret;
+ }
+ i2c-speed_hz = speed;
+
+ return 0;
+}
+
+/*
+ * 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);
+}
+
+int i2c_set_addr_len(struct udevice *dev, uint addr_len)
+{
+ struct udevice *bus = dev-parent;
+ struct dm_i2c_chip *chip = dev_get_parentdata(dev);
+ struct dm_i2c_ops *ops = i2c_get_ops(bus);
+ int ret;
+
+ if (addr_len 3)
+ return -EINVAL;
+ if (ops-set_addr_len) {
+ ret = ops-set_addr_len(dev, addr_len);
+ if (ret)
+ return ret;
+ }
+ chip-addr_len = addr_len;
+
+ return 0;
+}
+
+int i2c_chip_ofdata_to_platdata(const void *blob, int node,
+
[U-Boot] [RFC PATCH 01/12] dm: core: Allow access to the device's driver_id data
When the device is created from a device tree node, it matches a compatible
string. Allow access to that string and the associated data.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/core/device.c | 5 +
drivers/core/lists.c | 17 -
include/dm/device.h | 11 +++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 49faa29..0d84776 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -548,3 +548,8 @@ int device_find_next_child(struct udevice **devp)
return 0;
}
+
+ulong dev_get_of_data(struct udevice *dev)
+{
+ return dev-of_id-data;
+}
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 699f94b..f170ae7 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -96,22 +96,26 @@ int lists_bind_drivers(struct udevice *parent, bool
pre_reloc_only)
* tree error
*/
static int driver_check_compatible(const void *blob, int offset,
- const struct udevice_id *of_match)
+ const struct udevice_id *of_match,
+ const struct udevice_id **of_idp)
{
int ret;
+ *of_idp = NULL;
if (!of_match)
return -ENOENT;
while (of_match-compatible) {
ret = fdt_node_check_compatible(blob, offset,
of_match-compatible);
- if (!ret)
+ if (!ret) {
+ *of_idp = of_match;
return 0;
- else if (ret == -FDT_ERR_NOTFOUND)
+ } else if (ret == -FDT_ERR_NOTFOUND) {
return -ENODEV;
- else if (ret 0)
+ } else if (ret 0) {
return -EINVAL;
+ }
of_match++;
}
@@ -123,6 +127,7 @@ int lists_bind_fdt(struct udevice *parent, const void
*blob, int offset,
{
struct driver *driver = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
+ const struct udevice_id *id;
struct driver *entry;
struct udevice *dev;
bool found = false;
@@ -134,7 +139,8 @@ int lists_bind_fdt(struct udevice *parent, const void
*blob, int offset,
if (devp)
*devp = NULL;
for (entry = driver; entry != driver + n_ents; entry++) {
- ret = driver_check_compatible(blob, offset, entry-of_match);
+ ret = driver_check_compatible(blob, offset, entry-of_match,
+ id);
name = fdt_get_name(blob, offset, NULL);
if (ret == -ENOENT) {
continue;
@@ -154,6 +160,7 @@ int lists_bind_fdt(struct udevice *parent, const void
*blob, int offset,
dm_warn(Error binding driver '%s'\n, entry-name);
return ret;
} else {
+ dev-of_id = id;
found = true;
if (devp)
*devp = dev;
diff --git a/include/dm/device.h b/include/dm/device.h
index b8d4e7a..a712156 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -47,6 +47,7 @@ struct driver_info;
* @name: Name of device, typically the FDT node name
* @platdata: Configuration data for this device
* @of_offset: Device tree node offset for this device (- for none)
+ * @of_id: Pointer to the udevice_id structure which created the device
* @parent: Parent of this device, or NULL for the top level device
* @priv: Private data for this device
* @uclass: Pointer to uclass for this device
@@ -65,6 +66,7 @@ struct udevice {
const char *name;
void *platdata;
int of_offset;
+ const struct udevice_id *of_id;
struct udevice *parent;
void *priv;
struct uclass *uclass;
@@ -200,6 +202,15 @@ void *dev_get_parentdata(struct udevice *dev);
void *dev_get_priv(struct udevice *dev);
/**
+ * dev_get_of_data() - get the device tree data used to bind a device
+ *
+ * When a device is bound using a device tree node, it matches a
+ * particular compatible string as in struct udevice_id. This function
+ * returns the associated data value for that compatible string
+ */
+ulong dev_get_of_data(struct udevice *dev);
+
+/**
* device_get_child() - Get the child of a device by index
*
* Returns the numbered child, 0 being the first. This does not use
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/12] RFC: dm: Add I2C support
(Note this is RFC since the uclass interface needs discussion and also because only sandbox is implemented so far. But I thought it best to get this out there as soon as I wrote it as it may influence the PMIC library, etc.) This series is an initial attempt to add 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. This series is available at u-boot-dm/i2c-working. Simon Glass (12): dm: core: Allow access to the device's driver_id data dm: core: Add functions to find parent and OF data 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: WIP: EEPROM driver dm: i2c: Add tests for I2C dm: i2c: tegra: Convert to driver model for I2C for seaboard arch/arm/cpu/tegra20-common/pmu.c | 21 +- arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +- arch/sandbox/dts/sandbox.dts| 17 ++ board/nvidia/common/board.c | 4 - common/cmd_i2c.c| 312 +++ drivers/core/device.c | 10 + drivers/core/lists.c| 17 +- drivers/i2c/Makefile| 2 + drivers/i2c/i2c-emul-uclass.c | 14 ++ drivers/i2c/i2c-uclass.c| 177 drivers/i2c/sandbox_i2c.c | 148 + drivers/i2c/tegra_i2c.c | 313 ++-- drivers/misc/Makefile | 4 + drivers/misc/i2c_eeprom.c | 51 + drivers/misc/i2c_eeprom_emul.c | 108 ++ drivers/power/tps6586x.c| 27 +-- include/config_fallbacks.h | 6 + include/configs/cardhu.h| 2 - include/configs/colibri_t30.h | 2 - include/configs/sandbox.h | 6 + include/configs/seaboard.h | 3 - include/configs/tegra-common.h | 1 + include/configs/tegra20-common.h| 3 - include/dm/device.h | 19 ++ include/dm/uclass-id.h | 3 + include/i2c.h | 252 ++ include/i2c_eeprom.h| 19 ++ include/tps6586x.h | 2 +- test/dm/Makefile| 1 + test/dm/i2c.c | 100 + test/dm/test.dts| 17 ++ 31 files changed, 1373 insertions(+), 290 deletions(-) create mode 100644 drivers/i2c/i2c-emul-uclass.c create mode 100644 drivers/i2c/i2c-uclass.c create mode 100644 drivers/i2c/sandbox_i2c.c create mode 100644 drivers/misc/i2c_eeprom.c create mode 100644 drivers/misc/i2c_eeprom_emul.c create mode 100644 include/i2c_eeprom.h create mode 100644 test/dm/i2c.c -- 2.1.0.rc2.206.gedb03e5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 07/12] 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
---
drivers/misc/Makefile | 3 ++
drivers/misc/i2c_eeprom_emul.c | 108 +
2 files changed, 111 insertions(+)
create mode 100644 drivers/misc/i2c_eeprom_emul.c
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..9a4c385
--- /dev/null
+++ b/drivers/misc/i2c_eeprom_emul.c
@@ -0,0 +1,108 @@
+/*
+ * 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
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sandbox_i2c_flash_plat_data {
+ const char *filename;
+ int size;
+};
+
+struct sandbox_i2c_flash {
+ uint8_t *data;
+};
+
+static int sandbox_i2c_eprom_probe_chip(struct udevice *dev, uint chip)
+{
+ return 0;
+}
+
+static int sandbox_i2c_eprom_read(struct udevice *dev, uint chip_addr,
+ uint addr, uint alen, uint8_t *buffer,
+ int len)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+ struct sandbox_i2c_flash *priv = dev_get_priv(dev);
+
+ if (addr + len plat-size)
+ return -EINVAL;
+ memcpy(buffer, priv-data + addr, len);
+
+ return 0;
+}
+
+static int sandbox_i2c_eprom_write(struct udevice *dev, uint chip_addr,
+ uint addr, uint alen, const uint8_t *buffer,
+ int len)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+ struct sandbox_i2c_flash *priv = dev_get_priv(dev);
+
+ if (addr + len plat-size)
+ return -EINVAL;
+ memcpy(priv-data + addr, buffer, len);
+
+ return 0;
+}
+
+struct dm_i2c_ops sandbox_i2c_emul_ops = {
+ .probe = sandbox_i2c_eprom_probe_chip,
+ .read = sandbox_i2c_eprom_read,
+ .write = sandbox_i2c_eprom_write,
+};
+
+static int sandbox_i2c_eeprom_ofdata_to_platdata(struct udevice *dev)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+
+ plat-size = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
+ sandbox,size, 32);
+ plat-filename = fdt_getprop(gd-fdt_blob, dev-of_offset,
+sandbox,filename, NULL);
+ if (!plat-filename) {
+ debug(%s: No filename for device '%s'\n, __func__,
+ dev-name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int sandbox_i2c_eeprom_probe(struct udevice *dev)
+{
+ struct sandbox_i2c_flash_plat_data *plat = dev_get_platdata(dev);
+ struct sandbox_i2c_flash *priv = dev_get_priv(dev);
+
+ priv-data = calloc(1, plat-size);
+ if (!priv-data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static const struct udevice_id sandbox_i2c_ids[] = {
+ { .compatible = sandbox,i2c-eeprom },
+ { }
+};
+
+U_BOOT_DRIVER(sandbox_i2c_emul) = {
+ .name = sandbox_i2c_eeprom_emul,
+ .id = UCLASS_I2C_EMUL,
+ .of_match = sandbox_i2c_ids,
+ .ofdata_to_platdata = sandbox_i2c_eeprom_ofdata_to_platdata,
+ .probe = sandbox_i2c_eeprom_probe,
+ .priv_auto_alloc_size = sizeof(struct sandbox_i2c_flash),
+ .platdata_auto_alloc_size = sizeof(struct sandbox_i2c_flash_plat_data),
+ .ops= sandbox_i2c_emul_ops,
+};
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 11/12] 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
---
test/dm/Makefile | 1 +
test/dm/i2c.c| 100 +++
test/dm/test.dts | 17 ++
3 files changed, 118 insertions(+)
create mode 100644 test/dm/i2c.c
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..d2ee19d
--- /dev/null
+++ b/test/dm/i2c.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright (C) 2013 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#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
+
+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;
+ 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));
+ ut_asserteq(-ENODEV, i2c_probe(bus, no_chip));
+ 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_addr_len(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_addr_len(dev, 1));
+ ut_assertok(i2c_read(dev, 0, buf, 5));
+
+ /* The sandbox driver allows this setting, but then fails reads */
+ ut_assertok(i2c_set_addr_len(dev, 2));
+ ut_asserteq(-EINVAL, i2c_read(dev, 0, buf, 5));
+
+ /* This is not supported by the uclass */
+ ut_asserteq(-EINVAL, i2c_set_addr_len(dev, 4));
+
+ /* This is faulted by the sandbox driver */
+ ut_asserteq(-EINVAL, i2c_set_addr_len(dev, 3));
+
+ return 0;
+}
+DM_TEST(dm_test_i2c_addr_len, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
diff --git a/test/dm/test.dts b/test/dm/test.dts
index 1fba792..69991a3 100644
--- a/test/dm/test.dts
+++ b/test/dm/test.dts
@@ -93,6 +93,23 @@
num-gpios = 10;
};
+ i2c@0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0;
+ compatible = sandbox,i2c;
+ clock-frequency = 10;
+ 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.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
[U-Boot] [RFC PATCH 04/12] 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
---
common/cmd_i2c.c | 312 +++
1 file changed, 267 insertions(+), 45 deletions(-)
diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index c266b88..6766856 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';
@@ -229,6 +285,10 @@ static int do_i2c_read ( cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
u_char chip;
uintdevaddr, alen, length;
u_char *memaddr;
+ int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+#endif
if (argc != 5)
return CMD_RET_USAGE;
@@ -243,7 +303,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,10 +317,18 @@ 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_addr_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;
}
@@ -269,6 +337,10 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[
u_char chip;
uintdevaddr, alen, length;
u_char *memaddr;
+ int ret;
+#ifdef CONFIG_DM_I2C
+ struct udevice *dev;
+#endif
if (argc != 5)
return cmd_usage(cmdtp);
@@ -288,7 +360,7 @@ static int do_i2c_write(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[3], NULL, 16);
- alen = get_alen(argv[3]);
+ alen = get_alen(argv[3], DEFAULT_ADDR_LEN);
if (alen 3)
return cmd_usage(cmdtp);
@@ -297,10 +369,22 @@
[U-Boot] [RFC PATCH 09/12] 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
---
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.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 10/12] dm: WIP: EEPROM driver
There seem to be a few EEPROM drivers around - perhaps we should have a
single standard one?
This is little more than a placeholder at present.
Signed-off-by: Simon Glass s...@chromium.org
---
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 9e20d31..8f389df 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -30,6 +30,7 @@ enum uclass_id {
UCLASS_SPI_FLASH, /* SPI flash */
UCLASS_CROS_EC, /* Chrome OS EC */
UCLASS_I2C, /* I2C bus */
+ 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.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 06/12] 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.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/i2c/Makefile | 2 +-
drivers/i2c/sandbox_i2c.c | 148 ++
2 files changed, 149 insertions(+), 1 deletion(-)
create mode 100644 drivers/i2c/sandbox_i2c.c
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 10edea6..ea18228 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..3beb0f9
--- /dev/null
+++ b/drivers/i2c/sandbox_i2c.c
@@ -0,0 +1,148 @@
+/*
+ * 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 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;
+
+ 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_probe_chip(struct udevice *bus, uint chip_addr)
+{
+ struct dm_i2c_ops *ops;
+ struct udevice *emul;
+ int ret;
+
+ ret = get_emul(bus, chip_addr, emul, ops);
+ if (ret)
+ return ret;
+
+ return ops-probe(emul, chip_addr);
+}
+
+static int sandbox_i2c_read(struct udevice *bus, uint chip_addr, uint addr,
+ uint alen, uint8_t *buffer, int len)
+{
+ struct dm_i2c_bus *i2c = bus-uclass_priv;
+ struct dm_i2c_ops *ops;
+ struct udevice *emul;
+ int ret;
+
+ ret = get_emul(bus, chip_addr, emul, ops);
+ if (ret)
+ return ret;
+
+ /* For testing, don't allow reading above 400KHz */
+ if (i2c-speed_hz 40 || alen != 1)
+ return -EINVAL;
+ return ops-read(emul, chip_addr, addr, alen, buffer, len);
+}
+
+static int sandbox_i2c_write(struct udevice *bus, uint chip_addr, uint addr,
+uint alen, const uint8_t *buffer, int len)
+{
+ struct dm_i2c_bus *i2c = bus-uclass_priv;
+ struct dm_i2c_ops *ops;
+ struct udevice *emul;
+ int ret;
+
+ ret = get_emul(bus, chip_addr, emul, ops);
+ if (ret)
+ return ret;
+
+ /* For testing, don't allow writing above 100KHz */
+ if (i2c-speed_hz 10 || alen != 1)
+ return -EINVAL;
+ return ops-write(emul, chip_addr, addr, alen, buffer, len);
+}
+
+static int sandbox_i2c_set_addr_len(struct udevice *dev, uint addr_len)
+{
+ if (addr_len == 3)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct dm_i2c_ops sandbox_i2c_ops = {
+ .probe = sandbox_i2c_probe_chip,
+ .read = sandbox_i2c_read,
+ .write = sandbox_i2c_write,
+ .set_addr_len = sandbox_i2c_set_addr_len,
+};
+
+static int sandbox_i2c_child_pre_probe(struct udevice *dev)
+{
+ struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
+
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
+ i2c_chip);
+}
+
+static const struct udevice_id
[U-Boot] [RFC PATCH 05/12] 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
---
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 2ee468d..10edea6 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 9611a13..9e20d31 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.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 02/12] dm: core: Add functions to find parent and OF data
Add dev_get_parent() as a convenience to obtain the parent of a device.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/core/device.c | 5 +
include/dm/device.h | 8
2 files changed, 13 insertions(+)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 0d84776..76b29fd 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -549,6 +549,11 @@ int device_find_next_child(struct udevice **devp)
return 0;
}
+struct udevice *dev_get_parent(struct udevice *child)
+{
+ return child-parent;
+}
+
ulong dev_get_of_data(struct udevice *dev)
{
return dev-of_id-data;
diff --git a/include/dm/device.h b/include/dm/device.h
index a712156..e8b7fcf 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -202,6 +202,14 @@ void *dev_get_parentdata(struct udevice *dev);
void *dev_get_priv(struct udevice *dev);
/**
+ * struct dev_get_parent() - Get the parent of a device
+ *
+ * @child: Child to check
+ * @return parent of child, or NULL if this is the root device
+ */
+struct udevice *dev_get_parent(struct udevice *child);
+
+/**
* dev_get_of_data() - get the device tree data used to bind a device
*
* When a device is bound using a device tree node, it matches a
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 12/12] dm: i2c: tegra: Convert to driver model for I2C for seaboard
This converts seaboard over to use driver model for I2C. This is so far
untested and only useful for broad comments / review. To complete this,
trimslice and whistler will also need conversion.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/tegra20-common/pmu.c | 21 +-
arch/arm/include/asm/arch-tegra/tegra_i2c.h | 2 +-
board/nvidia/common/board.c | 4 -
drivers/i2c/tegra_i2c.c | 313 ++--
drivers/power/tps6586x.c| 27 +--
include/configs/cardhu.h| 2 -
include/configs/colibri_t30.h | 2 -
include/configs/seaboard.h | 3 -
include/configs/tegra-common.h | 1 +
include/configs/tegra20-common.h| 3 -
include/tps6586x.h | 2 +-
11 files changed, 140 insertions(+), 240 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/include/asm/arch-tegra/tegra_i2c.h
b/arch/arm/include/asm/arch-tegra/tegra_i2c.h
index 7ca6907..eeeb247 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_i2c.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_i2c.h
@@ -167,6 +167,6 @@ struct i2c_ctlr {
*
* @return number of bus, or -1 if there is no DVC active
*/
-int tegra_i2c_get_dvc_bus_num(void);
+int tegra_i2c_get_dvc_bus(struct udevice **busp);
#endif /* _TEGRA_I2C_H_ */
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 03f055d..7226fa4 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -132,10 +132,6 @@ int board_init(void)
power_det_init();
#ifdef CONFIG_SYS_I2C_TEGRA
-#ifndef CONFIG_SYS_I2C_INIT_BOARD
-#error You must define CONFIG_SYS_I2C_INIT_BOARD to use i2c on Nvidia boards
-#endif
- i2c_init_board();
# ifdef CONFIG_TEGRA_PMU
if (pmu_set_nominal())
debug(Failed to select nominal voltages\n);
diff --git a/drivers/i2c/tegra_i2c.c b/drivers/i2c/tegra_i2c.c
index 257b72f..85a6837 100644
--- a/drivers/i2c/tegra_i2c.c
+++ b/drivers/i2c/tegra_i2c.c
@@ -7,6 +7,8 @@
*/
#include common.h
+#include dm.h
+#include errno.h
#include fdtdec.h
#include i2c.h
#include asm/io.h
@@ -19,6 +21,12 @@
DECLARE_GLOBAL_DATA_PTR;
+enum i2c_type {
+ TYPE_114,
+ TYPE_STD,
+ TYPE_DVC,
+};
+
/* Information about i2c controller */
struct i2c_bus {
int id;
@@ -27,20 +35,17 @@ struct i2c_bus {
int pinmux_config;
struct i2c_control *control;
struct i2c_ctlr *regs;
- int is_dvc; /* DVC type, rather than I2C */
- int is_scs; /* single clock source (T114+) */
+ enum i2c_type type;
int inited; /* bus is inited */
};
-static struct i2c_bus i2c_controllers[TEGRA_I2C_NUM_CONTROLLERS];
-
static void set_packet_mode(struct i2c_bus *i2c_bus)
{
u32 config;
config = I2C_CNFG_NEW_MASTER_FSM_MASK | I2C_CNFG_PACKET_MODE_MASK;
- if (i2c_bus-is_dvc) {
+ if (i2c_bus-type == TYPE_DVC) {
struct dvc_ctlr *dvc = (struct dvc_ctlr *)i2c_bus-regs;
writel(config, dvc-cnfg);
@@ -73,7 +78,7 @@ static void i2c_init_controller(struct i2c_bus *i2c_bus)
clock_start_periph_pll(i2c_bus-periph_id, CLOCK_ID_PERIPH,
i2c_bus-speed * 2 * 8);
- if (i2c_bus-is_scs) {
+ if
Re: [U-Boot] [PATCH] imx: mx6 sabreauto: Add board support for USB EHCI
On 10/10/2014 7:46 PM, Fabio Estevam wrote:
On Fri, Oct 10, 2014 at 6:01 AM, Ye.Li b37...@freescale.com wrote:
On mx6 sabreauto board, there are two USB ports:
0: OTG
1: HOST
The EHCI driver is enabled for this board, but the IOMUX and VBUS power
control is not implemented, which cause both USB port failed to work.
This patch fix the problem by adding the BSP support.
BSP is a broad term here.
Since the power control uses the GPIO pin from port expander MAX7310,
the PCA953X driver is enabled for accessing the MAX7310.
The ID pin of OTG Port needs to configure the GPR1 bit 13 for selecting
its daisy chain. Add a new function imx_iomux_set_gpr_register to
handle GPR register setting.
Signed-off-by: Ye.Li b37...@freescale.com
---
arch/arm/imx-common/iomux-v3.c| 17 +-
arch/arm/include/asm/imx-common/iomux-v3.h|7 ++-
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 89
-
include/configs/mx6qsabreauto.h |5 +-
4 files changed, 114 insertions(+), 4 deletions(-)
diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
index 22cd11a..2d96655 100644
--- a/arch/arm/imx-common/iomux-v3.c
+++ b/arch/arm/imx-common/iomux-v3.c
@@ -4,7 +4,7 @@
* Copyright (C) 2009 by Jan Weitzel Phytec Messtechnik GmbH,
* armli...@phytec.de
*
- * Copyright (C) 2004-2011 Freescale Semiconductor, Inc.
+ * Copyright (C) 2004-2014 Freescale Semiconductor, Inc.
I don't see the need for changing the copyright everytime you touch a
file. Same apply to other files in this patch.
+static int port_exp_direction_output(unsigned gpio, int value)
+{
+ int ret;
+
+ i2c_set_bus_num(2);
+ if (i2c_probe(PORTEXP_IO_TO_CHIP(gpio)))
+ return -ENXIO;
Would be better like this:
ret = i2c_probe(PORTEXP_IO_TO_CHIP(gpio))
if (ret)
return ret;
+
+ ret = pca953x_set_dir(PORTEXP_IO_TO_CHIP(gpio),
+ (1 PORTEXP_IO_TO_PIN(gpio)),
+ (PCA953X_DIR_OUT PORTEXP_IO_TO_PIN(gpio)));
Here you can do:
if (ret)
return ret;
+
+ if (!ret)
Then you don't need to check for !ret here
+ ret = pca953x_set_val(PORTEXP_IO_TO_CHIP(gpio),
+ (1 PORTEXP_IO_TO_PIN(gpio)),
+ (value PORTEXP_IO_TO_PIN(gpio)));
+
+ if (ret)
+ ret = -EIO;
+
+ return ret;
+}
if (ret)
return ret;
return 0;
+int board_ehci_hcd_init(int port)
+{
+ switch (port) {
+ case 0:
+ imx_iomux_v3_setup_multiple_pads(usb_otg_pads,
+ ARRAY_SIZE(usb_otg_pads));
+
+ /*set daisy chain for otg_pin_id on 6q. for 6dl, this bit is
reserved*/
+ imx_iomux_set_gpr_register(1, 13, 1, 0);
+ break;
+ case 1:
+ break;
+ default:
+ printf(MXC USB port %d not yet supported\n, port);
+ return 1;
return -EINVAL;
+int board_ehci_power(int port, int on)
+{
+ switch (port) {
+ case 0:
+ if (on)
+ port_exp_direction_output(USB_OTG_PWR, 1);
+ else
+ port_exp_direction_output(USB_OTG_PWR, 0);
+ break;
+ case 1:
+ if (on)
+ port_exp_direction_output(USB_HOST1_PWR, 1);
+ else
+ port_exp_direction_output(USB_HOST1_PWR, 0);
+ break;
+ default:
+ printf(MXC USB port %d not yet supported\n, port);
+ return 1;
return -EINVAL;
I will update per your comments.
For the copyright, in FSL we are asked to update it when applying any change to
the file. what's the rule used in community?
Best regards,
Ye Li
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
