May 2015 - U-Boot

Re: [U-Boot] [PATCH 1/6] usb: dwc2: Add support for v3 snpsid value
by Marek Vasut 13 May '15

13 May '15

On Tuesday, May 12, 2015 at 03:38:27 PM, Peter Griffin wrote: > This has been tested to the extent that I can enumerate > a asix usb networking adapter and boot a kernel over usb > on the 96boards hikey u-boot port I'm currently doing. > > Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> > --- > drivers/usb/host/dwc2.c | 3 ++- > drivers/usb/host/dwc2.h | 1 + > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c > index e8142ac..19a6007 100644 > --- a/drivers/usb/host/dwc2.c > +++ b/drivers/usb/host/dwc2.c > @@ -1015,7 +1015,8 @@ int usb_lowlevel_init(int index, enum usb_init_type > init, void **controller) snpsid = readl(&regs->gsnpsid); > printf("Core Release: %x.%03x\n", snpsid >> 12 & 0xf, snpsid & 0xfff); > > - if ((snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_2xx) { > + if ((snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_2xx && > + (snpsid & DWC2_SNPSID_DEVID_MASK) != DWC2_SNPSID_DEVID_VER_3xx) { Isn't this then a DWC3 controller instead ? Best regards, Marek Vasut

2 2

[U-Boot] [PATCH] usb: kbd: Fix key repeat not always using
by Hans de Goede 13 May '15

13 May '15

The usb-kbd key repeat code assumes that reports get repeated every 40 ms, this is never true when using CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP, and does not always works for CONFIG_SYS_USB_EVENT_POLL and CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE since not all usb keyboards honor the usb_set_idle() command. For CONFIG_SYS_USB_EVENT_POLL we must use usb_set_idle() since we do a blocking wait for the hid report, so if we do not tell the keyboard to send a hid report every 40ms even if nothing changes then we will block u-boot for 1s (the default u-boot usb interrupt packet timeout). Note that in this case on keyboards which do not support usb_set_idle() we loose and we actually get 1s latencies on other u-boot activities. For the other poll-methods this commit stops using usb_set_idle() and instead repeats the last received hid-report every 40 ms as long as no new hid-report is received. This fixes key-repeat not working at all with CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP and fixes it not working with keyboards which do not implement usb_set_idle() when using CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- common/usb_kbd.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/common/usb_kbd.c b/common/usb_kbd.c index 24a1a56..d4733b1 100644 --- a/common/usb_kbd.c +++ b/common/usb_kbd.c @@ -31,7 +31,7 @@ int overwrite_console(void) #endif /* Keyboard sampling rate */ -#define REPEAT_RATE (40 / 4) /* 40msec -> 25cps */ +#define REPEAT_RATE 40 /* 40msec -> 25cps */ #define REPEAT_DELAY 10 /* 10 x REPEAT_RATE = 400msec */ #define NUM_LOCK 0x53 @@ -103,6 +103,7 @@ struct usb_kbd_pdata { unsigned long intpipe; int intpktsize; int intinterval; + int last_report; struct int_queue *intq; uint32_t repeat_delay; @@ -318,15 +319,16 @@ static inline void usb_kbd_poll_for_event(struct usb_device *dev) data->intinterval); usb_kbd_irq_worker(dev); -#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP) +#else +# if defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP) struct usb_interface *iface; struct usb_kbd_pdata *data = dev->privptr; iface = &dev->config.if_desc[0]; usb_get_report(dev, iface->desc.bInterfaceNumber, 1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE); - if (memcmp(data->old, data->new, USB_KBD_BOOT_REPORT_SIZE)) + if (memcmp(data->old, data->new, USB_KBD_BOOT_REPORT_SIZE)) { usb_kbd_irq_worker(dev); -#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE) +# elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE) struct usb_kbd_pdata *data = dev->privptr; if (poll_int_queue(dev, data->intq)) { usb_kbd_irq_worker(dev); @@ -335,6 +337,13 @@ static inline void usb_kbd_poll_for_event(struct usb_device *dev) data->intq = create_int_queue(dev, data->intpipe, 1, USB_KBD_BOOT_REPORT_SIZE, data->new, data->intinterval); +# endif + data->last_report = get_timer(0); + /* Repeat last usb hid report every REPEAT_RATE ms for keyrepeat */ + } else if (data->last_report != -1 && + get_timer(data->last_report) > REPEAT_RATE) { + usb_kbd_irq_worker(dev); + data->last_report = get_timer(0); } #endif } @@ -445,12 +454,15 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned int ifnum) data->intpktsize = min(usb_maxpacket(dev, data->intpipe), USB_KBD_BOOT_REPORT_SIZE); data->intinterval = ep->bInterval; + data->last_report = -1; /* We found a USB Keyboard, install it. */ usb_set_protocol(dev, iface->desc.bInterfaceNumber, 0); +#ifdef CONFIG_SYS_USB_EVENT_POLL debug("USB KBD: found set idle...\n"); - usb_set_idle(dev, iface->desc.bInterfaceNumber, REPEAT_RATE, 0); + usb_set_idle(dev, iface->desc.bInterfaceNumber, REPEAT_RATE / 4, 0); +#endif debug("USB KBD: enable interrupt pipe...\n"); #ifdef CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE -- 2.3.6

3 4

Re: [U-Boot] [PATCH 2/6] dm: gpio: hi6220: Add a hi6220 GPIO driver model driver.
by Marek Vasut 13 May '15

13 May '15

On Tuesday, May 12, 2015 at 03:38:28 PM, Peter Griffin wrote: Hi! > This patch adds support for the GPIO perif found on hi6220 > SoC. > > Signed-off-by: Peter Griffin <peter.griffin(a)linaro.org> > --- > arch/arm/include/asm/arch-armv8/gpio.h | 47 +++++++++++++++++ > drivers/gpio/Makefile | 2 + > drivers/gpio/hi6220_gpio.c | 95 > ++++++++++++++++++++++++++++++++++ 3 files changed, 144 insertions(+) > create mode 100644 arch/arm/include/asm/arch-armv8/gpio.h > create mode 100644 drivers/gpio/hi6220_gpio.c > > diff --git a/arch/arm/include/asm/arch-armv8/gpio.h > b/arch/arm/include/asm/arch-armv8/gpio.h new file mode 100644 > index 0000000..162c2d9 > --- /dev/null > +++ b/arch/arm/include/asm/arch-armv8/gpio.h > @@ -0,0 +1,47 @@ > +/* > + * Copyright (C) 2015 Linaro > + * Peter Griffin <peter.griffin(a)linaro.org> > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#ifndef _HI6220_GPIO_H_ > +#define _HI6220_GPIO_H_ > + > +#define HI6220_GPIO0_BASE (void *)0xf8011000 You should drop the explicit cast, that's nasty. Also, why don't you define this as a HI6220_GPIO_BASE(bank) instead? That'd trim down the number of macros and from what I see, it should be rather easy to do ... #define HI6220_GPIO_BASE(bank) (((bank < 4) ? 0xf8012000 : (0xf7020000 - 0x4000)) + (0x1000 * bank)) > +#define HI6220_GPIO1_BASE (void *)0xf8012000 > +#define HI6220_GPIO2_BASE (void *)0xf8013000 > +#define HI6220_GPIO3_BASE (void *)0xf8014000 > +#define HI6220_GPIO4_BASE (void *)0xf7020000 > +#define HI6220_GPIO5_BASE (void *)0xf7021000 > +#define HI6220_GPIO6_BASE (void *)0xf7022000 > +#define HI6220_GPIO7_BASE (void *)0xf7023000 > +#define HI6220_GPIO8_BASE (void *)0xf7024000 > +#define HI6220_GPIO9_BASE (void *)0xf7025000 > +#define HI6220_GPIO10_BASE (void *)0xf7026000 > +#define HI6220_GPIO11_BASE (void *)0xf7027000 > +#define HI6220_GPIO12_BASE (void *)0xf7028000 > +#define HI6220_GPIO13_BASE (void *)0xf7029000 > +#define HI6220_GPIO14_BASE (void *)0xf702a000 > +#define HI6220_GPIO15_BASE (void *)0xf702b000 > +#define HI6220_GPIO16_BASE (void *)0xf702c000 > +#define HI6220_GPIO17_BASE (void *)0xf702d000 > +#define HI6220_GPIO18_BASE (void *)0xf702e000 > +#define HI6220_GPIO19_BASE (void *)0xf702f000 But are these even used in the driver anywhere ? > +#define BIT(x) (1 << (x)) This macro should be placed into common header files. > +#define HI6220_GPIO_PER_BANK 8 > +#define HI6220_GPIO_DIR 0x400 > + > +struct gpio_bank { > + u8 *base; /* address of registers in physical memory */ Should be void __iomem *, no ? > +}; > + > +/* Information about a GPIO bank */ > +struct hikey_gpio_platdata { > + int bank_index; > + void *base; /* address of registers in physical memory */ > +}; > + > +#endif /* _HI6220_GPIO_H_ */ [...]

3 3

[U-Boot] [PATCH v5 00/15] usb: ohci dm support & add sunxi ehci + ohci support
by Hans de Goede 13 May '15

13 May '15

Hi All, Here is a new series which applies on top of u-boot-dm/master, this contains all my usb (dm) ohci / ehci / sunxi patches which have been posted before and not yet merged. The series is at v5 because for a couple of patches from my first posting of the ehci sunxi dm series this is the 5th posting, for most patches this is the 2nd posting. Marek, can we please have your ack for patches 1-4 and 11-12, then Simon can merge the entire series through the u-boot-dm tree. Changes since the previous posting of these patches: -"usb: usb: usb_control_msg() propagate controller error code" New patch in this version -"usb: legacy_hub_port_reset() check and propagate usb_set_port_feature() errors" New patch in this version -"usb: Stop reset procedure when a dev is handed over to a companion hcd" Rewritten to not use an usb_companion_device_count global variable -"dm: usb: Add support for interrupt queues to the dm ehci code": squashed into "dm: usb: Add support for interrupt queues to the dm usb code" so as to not have a not building intermediate state -"dm: usb: Add support for companion controllers" Check device_active() before touching the controllers -"dm: usb: Do not scan companion buses if no devices where handed over" Make companion_device_count an uclass private variable -"usb: ohci: Do not resubmit and leak urbs for interrupt packets" Improved commit message -"usb: ohci: Remove unnecessary delays from hc_start and power power-on paths" Improved commit message -"usb: ohci: Skip unnecessary mdelay(1) calls in various places" Add a ohci_mdelay helper macro -"usb: ohci: Add dm support" Fixed TODO about freeing resources on deregister -"sunxi: ohci: Add ohci usb host controller support" Fixed build failure on sun6i / sun8i, added some extra comments to the code Thanks & Regards, Hans

4 44

[U-Boot] [PATCH 1/3] net: Implement random ethaddr fallback in eth.c
by Joe Hershberger 13 May '15

13 May '15

Implement the random ethaddr fallback in eth.c so it is in a common place and not reimplemented in each board or driver that wants this behavior. Signed-off-by: Joe Hershberger <joe.hershberger(a)ni.com> --- To function properly in the driver-model case, this patch requires that https://patchwork.ozlabs.org/patch/467418/ be applied. README | 3 ++- doc/README.enetaddr | 2 ++ net/Kconfig | 8 ++++++++ net/eth.c | 12 ++++++++++++ 4 files changed, 24 insertions(+), 1 deletion(-) diff --git a/README b/README index ee65fdb..9e90c4b 100644 --- a/README +++ b/README @@ -5629,7 +5629,8 @@ o If both the SROM and the environment contain a MAC address, and the warning is printed. o If neither SROM nor the environment contain a MAC address, an error - is raised. + is raised. If CONFIG_NET_RANDOM_ETHADDR is defined, then in this case + a random, locally-assigned MAC is used. If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses will be programmed into hardware as part of the initialization process. This diff --git a/doc/README.enetaddr b/doc/README.enetaddr index 0fafd2c..82c9cd5 100644 --- a/doc/README.enetaddr +++ b/doc/README.enetaddr @@ -37,6 +37,8 @@ Correct flow of setting up the MAC address (summarized): environment variable will be used unchanged. If the environment variable is not set, it will be initialized from eth_device->enetaddr, and a warning will be printed. + If both are invalid and CONFIG_NET_RANDOM_ETHADDR is defined, a random, + locally-assigned MAC is written to eth_device->enetaddr. 4. Program the address into hardware if the following conditions are met: a) The relevant driver has a 'write_addr' function b) The user hasn't set an 'ethmacskip' environment variable diff --git a/net/Kconfig b/net/Kconfig index 22b9eaa..a2bd4fe 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -7,4 +7,12 @@ menuconfig NET if NET +config NET_RANDOM_ETHADDR + bool "Random ethaddr if unset" + help + Selecting this will allow the Ethernet interface to function + even when the ethaddr variable for that interface is unset. + A new MAC address will be generated on every boot and it will + not be added to the environment. + endif # if NET diff --git a/net/eth.c b/net/eth.c index 8e6acfe..c4e0878 100644 --- a/net/eth.c +++ b/net/eth.c @@ -529,9 +529,15 @@ static int eth_post_probe(struct udevice *dev) printf("\nWarning: %s using MAC address from ROM\n", dev->name); } else if (is_zero_ethaddr(pdata->enetaddr)) { +#ifdef CONFIG_NET_RANDOM_ETHADDR + net_random_ethaddr(pdata->enetaddr); + printf("\nWarning: %s (eth%d) using random MAC address - %pM\n", + dev->name, dev->seq, pdata->enetaddr); +#else printf("\nError: %s address not set.\n", dev->name); return -EINVAL; +#endif } return 0; @@ -657,9 +663,15 @@ int eth_write_hwaddr(struct eth_device *dev, const char *base_name, printf("\nWarning: %s using MAC address from net device\n", dev->name); } else if (is_zero_ethaddr(dev->enetaddr)) { +#ifdef CONFIG_NET_RANDOM_ETHADDR + net_random_ethaddr(dev->enetaddr); + printf("\nWarning: %s (eth%d) using random MAC address - %pM\n", + dev->name, eth_number, dev->enetaddr); +#else printf("\nError: %s address not set.\n", dev->name); return -EINVAL; +#endif } if (dev->write_hwaddr && !eth_mac_skip(eth_number)) { -- 1.7.11.5

6 14

[U-Boot] [PATCH v2 1/4] usb: ohci: Do not reuse ed for interrupt endpoints of different devices
by Hans de Goede 13 May '15

13 May '15

When submitting interrupt packets to an endpoint we only link in the ed once to avoid some races surrounding unlinking of periodic endpoints, but we share one ohci_device struct / one set of ed-s for all devices, which means that if we have an interrupt endpoint at endpoint 1 with one device, and a non interrupt endpoint 1 with another device we end up with the same ed linked into both the periodic and async lists, which is not good (tm). This commit switches over to using separate ohci_device structs, and thus separate ed-s for devices with interrupt endpoints, fixing this. This fixes e.g. matching a usb storage device and keyboard on the same usb-1 hub not working. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Marek Vasut <marex(a)denx.de> --- drivers/usb/host/ohci-hcd.c | 35 ++++++++++++++++++++++++++++++++++- drivers/usb/host/ohci.h | 4 ++++ 2 files changed, 38 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 2f976d2..5364ced 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1478,6 +1478,31 @@ pkt_print(ohci, NULL, dev, pipe, buffer, transfer_len, /*-------------------------------------------------------------------------*/ +static ohci_dev_t *ohci_get_ohci_dev(ohci_t *ohci, int devnum, int intr) +{ + int i; + + if (!intr) + return &ohci->ohci_dev; + + /* First see if we already have an ohci_dev for this dev. */ + for (i = 0; i < NUM_INT_DEVS; i++) { + if (ohci->int_dev[i].devnum == devnum) + return &ohci->int_dev[i]; + } + + /* If not then find a free one. */ + for (i = 0; i < NUM_INT_DEVS; i++) { + if (ohci->int_dev[i].devnum == -1) { + ohci->int_dev[i].devnum = devnum; + return &ohci->int_dev[i]; + } + } + + printf("ohci: Error out of ohci_devs for interrupt endpoints\n"); + return NULL; +} + /* common code for handling submit messages - used for all but root hub */ /* accesses. */ static int submit_common_msg(ohci_t *ohci, struct usb_device *dev, @@ -1488,6 +1513,7 @@ static int submit_common_msg(ohci_t *ohci, struct usb_device *dev, int maxsize = usb_maxpacket(dev, pipe); int timeout; urb_priv_t *urb; + ohci_dev_t *ohci_dev; urb = malloc(sizeof(urb_priv_t)); memset(urb, 0, sizeof(urb_priv_t)); @@ -1511,7 +1537,11 @@ static int submit_common_msg(ohci_t *ohci, struct usb_device *dev, return -1; } - if (sohci_submit_job(ohci, &ohci->ohci_dev, urb, setup) < 0) { + ohci_dev = ohci_get_ohci_dev(ohci, dev->devnum, usb_pipeint(pipe)); + if (!ohci_dev) + return -ENOMEM; + + if (sohci_submit_job(ohci, ohci_dev, urb, setup) < 0) { err("sohci_submit_job failed"); return -1; } @@ -1711,8 +1741,11 @@ static int hc_start(ohci_t *ohci) { __u32 mask; unsigned int fminterval; + int i; ohci->disabled = 1; + for (i = 0; i < NUM_INT_DEVS; i++) + ohci->int_dev[i].devnum = -1; /* Tell the controller where the control and bulk lists are * The lists are empty now. */ diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h index 3f9869b..f1526d4 100644 --- a/drivers/usb/host/ohci.h +++ b/drivers/usb/host/ohci.h @@ -367,10 +367,13 @@ typedef struct #define NUM_TD 64 /* we need more TDs than EDs */ +#define NUM_INT_DEVS 8 /* num of ohci_dev structs for int endpoints */ + typedef struct ohci_device { ed_t ed[NUM_EDS] __aligned(ED_ALIGNMENT); td_t tds[NUM_TD] __aligned(TD_ALIGNMENT); int ed_cnt; + int devnum; } ohci_dev_t; /* @@ -384,6 +387,7 @@ typedef struct ohci_device { typedef struct ohci { /* this allocates EDs for all possible endpoints */ struct ohci_device ohci_dev __aligned(TD_ALIGNMENT); + struct ohci_device int_dev[NUM_INT_DEVS] __aligned(TD_ALIGNMENT); struct ohci_hcca *hcca; /* hcca */ /*dma_addr_t hcca_dma;*/ -- 2.4.0

2 7

[U-Boot] [PATCH] arc: remove dummy target
by Alexey Brodkin 13 May '15

13 May '15

TARGET_DUMMY was introduced to resolve the same problem as commit "arch: Make board selection choices optional" http://git.denx.de/?p=u-boot.git;a=commit;h=a26cd04920dc069fd6e91abb785426c… Latter implementation is much cleaner and appropriate. And anyways TARGET_DUMMY is no longer required. Signed-off-by: Alexey Brodkin <abrodkin(a)synopsys.com> Cc: Joe Hershberger <joe.hershberger(a)ni.com> --- arch/arc/Kconfig | 8 -------- 1 file changed, 8 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 85fddd2..67d28d3 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -134,14 +134,6 @@ choice prompt "Target select" optional -config TARGET_DUMMY - bool "Dummy target" - help - Please select one of real target boards below! - This target is only meant to force "makedefconfig" to put - TARGET_xxx in defconfig even this is the first target from the list - below. - config TARGET_TB100 bool "Support tb100" -- 2.1.0

2 2

[U-Boot] [PATCH] serial: stm32: Automatically generate CR when LF is observed
by Daniel Thompson 13 May '15

13 May '15

Currently the u-boot output looks rather odd when running the minicom terminal emulator in its default mode (just a string of "random" looking text down the right hand side of the screen). This is caused by a combination of minicom not automatically wrapping lines and the stm32 serial driver never sending a carriage return. Issue is trivially solved by automatically generating a CR whenever a LF is transmitted, Several other serial drivers implement this behaviour. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> Cc: Kamil Lulko <rev13(a)wp.pl> --- drivers/serial/serial_stm32.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c index 3c80096..8c613db 100644 --- a/drivers/serial/serial_stm32.c +++ b/drivers/serial/serial_stm32.c @@ -81,6 +81,10 @@ static int stm32_serial_getc(void) static void stm32_serial_putc(const char c) { struct stm32_serial *usart = (struct stm32_serial *)USART_BASE; + + if (c == '\n') + stm32_serial_putc('\r'); + while ((readl(&usart->sr) & USART_SR_FLAG_TXE) == 0) ; writel(c, &usart->dr); -- 2.1.0

4 4

[U-Boot] Patch to enable LEDs on sunxi/Cubietruck
by Prof. Dr. Gundolf Kiefer 13 May '15

13 May '15

Dear developers, the attached patch adds LED support for the Cubietruck board. I found that the support for the onboard leds is missing for sunxi-based boards in the latest Debian unstable and perhaps upstream version of U-Boot. IMHO LEDs are very helpful for headless systems. Perhaps the patch can be helpful somehow. The code has basically been ported from the U-Boot version maintained at linux-sunxi.org. As in the sunxi version, the blue led is switched on by default. Kind regards, Gundolf Kiefer Begin forwarded message: Date: Tue, 05 May 2015 09:46:39 -0700 From: Vagrant Cascadian <vagrant(a)aikidev.net> To: "Prof. Dr. Gundolf Kiefer" <gundolf.kiefer(a)hs-augsburg.de>, 783846(a)bugs.debian.org Subject: Re: Bug#783846: Patch to enable LEDs on sunix/Cubietruck On 2015-04-30, Prof. Dr. Gundolf Kiefer wrote: > It seems that the support for the onboard leds is missing for > sunxi-based boards even in the latest version (Debian unstable). IMHO > LEDs are very helpful for headless systems. Thanks for the patches! If you could submit these patches to u-boot upstream, that would be best; we're trying to minimize the patches that are not already included upstream. live well, vagrant --------------------------------------------------------------- Prof. Dr. Gundolf Kiefer Effiziente Eingebettete Systeme - Efficient Embedded Systems Fakultät für Informatik - Faculty of Computer Science Hochschule Augsburg - University of Applied Sciences http://www.hs-augsburg.de/~kiefer ---------------------------------------------------------------

4 3

[U-Boot] Booting mx28 from battery
by Fabio Estevam 13 May '15

13 May '15

Hi, Has anyone tested booting U-boot on mx28 powered by a battery only? >From a quick glance at arch/arm/cpu/arm926ejs/mxs/spl_power_init.c , it does appear to support it. I haven't tested it myself yet, but would like to hear if anyone has been successful with such configuration. Thanks, Fabio Estevam

2 2