Re: [PATCH v2] mtd: fix 'write: Invalid argument' while writing to nand-bb devices
On Thu, Jul 12, 2012 at 11:46:02AM +0200, Jan Luebbe wrote:
> The 'off_t cur_ofs' variable was missed during the 64 bit conversion.
> For the MEMGETBADBLOCK ioctl, a pointer to a loff_t is needed.
>
> Also adjust the debug format strings.
Applied, thanks
Sascha
>
> Signed-off-by: Jan Luebbe
> ---
> drivers/mtd/nand/nand-bb.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand-bb.c b/drivers/mtd/nand/nand-bb.c
> index 5b06a9e..519337e 100644
> --- a/drivers/mtd/nand/nand-bb.c
> +++ b/drivers/mtd/nand/nand-bb.c
> @@ -60,7 +60,7 @@ static ssize_t nand_bb_read(struct cdev *cdev, void *buf,
> size_t count,
> struct cdev *parent = bb->cdev_parent;
> int ret, bytes = 0, now;
>
> - debug("%s %d %d\n", __func__, offset, count);
> + debug("%s 0x%08llx %d\n", __func__, offset, count);
>
> while(count) {
> ret = cdev_ioctl(parent, MEMGETBADBLOCK, &bb->offset);
> @@ -96,7 +96,7 @@ static int nand_bb_write_buf(struct nand_bb *bb, size_t
> count)
> int ret, now;
> struct cdev *parent = bb->cdev_parent;
> void *buf = bb->writebuf;
> - off_t cur_ofs = bb->offset & ~(BB_WRITEBUF_SIZE - 1);
> + loff_t cur_ofs = bb->offset & ~(BB_WRITEBUF_SIZE - 1);
>
> while (count) {
> ret = cdev_ioctl(parent, MEMGETBADBLOCK, &cur_ofs);
> @@ -104,7 +104,7 @@ static int nand_bb_write_buf(struct nand_bb *bb, size_t
> count)
> return ret;
>
> if (ret) {
> - debug("skipping bad block at 0x%08x\n", cur_ofs);
> + debug("skipping bad block at 0x%08llx\n", cur_ofs);
> bb->offset += bb->info.erasesize;
> cur_ofs += bb->info.erasesize;
> continue;
> --
> 1.7.10.4
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] usb: gadget: enable for MXS
Hi Marc, On Thu, Jul 12, 2012 at 11:01:29PM +0200, Marc Kleine-Budde wrote: > Signed-off-by: Marc Kleine-Budde > --- > drivers/usb/gadget/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig > index f7f2697..df1d970 100644 > --- a/drivers/usb/gadget/Kconfig > +++ b/drivers/usb/gadget/Kconfig > @@ -4,7 +4,7 @@ menuconfig USB_GADGET > > config USB_HAVE_GADGET_DRIVER > bool > - default y if ARCH_IMX || ARCH_AT91 || ARCH_PXA > + default y if ARCH_IMX || ARCH_MXS || ARCH_AT91 || ARCH_PXA This does not seem to be enough. At least in my tree the driver itself depends on ARCH_IMX, so there is a ARCH_MXS missing there aswell. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] filetype: add forgotten mips barebox filetype_str
On Sun, Jul 15, 2012 at 04:21:57PM +0400, Antony Pavlov wrote:
> Signed-off-by: Antony Pavlov
Applied, thanks
Sascha
> ---
> common/filetype.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/common/filetype.c b/common/filetype.c
> index 39c2098..1a5b82d 100644
> --- a/common/filetype.c
> +++ b/common/filetype.c
> @@ -39,6 +39,7 @@ static const char *filetype_str[] = {
> [filetype_oftree] = "open firmware flat device tree",
> [filetype_aimage] = "Android boot image",
> [filetype_sh] = "Bourne Shell",
> + [filetype_mips_barebox] = "MIPS barebox image",
> };
>
> const char *file_type_to_string(enum filetype f)
> --
> 1.7.10
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 02/18] ARM/Samsung: unify device registration for the S3C24XX SoCs
On Fri, Jul 13, 2012 at 09:00:54PM +0200, Juergen Beisert wrote:
> Barebox crashes since it has trouble with a resource size of 0. Most of the
> S3C24XX based platforms crashes at runtime and can't use devices with resource
> sizes of 0 anymore. This patch fix it by unifying the device registration for
> all current Barebox's S3C24XX based platforms.
>
> - A9M2410 and A9M2440 compile time tested only.
> - Mini2440 also runtime tested.
So this is stuff for master, right?
Sascha
>
> Signed-off-by: Juergen Beisert
> ---
> arch/arm/boards/a9m2410/a9m2410.c |6 +--
> arch/arm/boards/a9m2440/a9m2440.c |7 ++-
> arch/arm/boards/mini2440/mini2440.c| 16 +++---
> .../mach-samsung/include/mach/devices-s3c24xx.h| 54
>
> 4 files changed, 65 insertions(+), 18 deletions(-)
> create mode 100644 arch/arm/mach-samsung/include/mach/devices-s3c24xx.h
>
> diff --git a/arch/arm/boards/a9m2410/a9m2410.c
> b/arch/arm/boards/a9m2410/a9m2410.c
> index eaafdbd..c2d4b87 100644
> --- a/arch/arm/boards/a9m2410/a9m2410.c
> +++ b/arch/arm/boards/a9m2410/a9m2410.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -109,8 +110,7 @@ static int a9m2410_devices_init(void)
> writel(reg, S3C_MISCCR);
>
> /* --- the devices the boot loader should work with */
> - add_generic_device("s3c24x0_nand", DEVICE_ID_DYNAMIC, NULL,
> S3C24X0_NAND_BASE,
> - 0, IORESOURCE_MEM, &nand_info);
> + s3c24xx_add_nand(&nand_info);
> /*
>* SMSC 91C111 network controller on the baseboard
>* connected to CS line 1 and interrupt line
> @@ -145,8 +145,6 @@ void __bare_init nand_boot(void)
>
> static int a9m2410_console_init(void)
> {
> - add_generic_device("s3c_serial", DEVICE_ID_DYNAMIC, NULL,
> S3C_UART1_BASE,
> - S3C_UART1_SIZE, IORESOURCE_MEM, NULL);
> return 0;
> }
>
> diff --git a/arch/arm/boards/a9m2440/a9m2440.c
> b/arch/arm/boards/a9m2440/a9m2440.c
> index 1d20248..8975c15 100644
> --- a/arch/arm/boards/a9m2440/a9m2440.c
> +++ b/arch/arm/boards/a9m2440/a9m2440.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -129,8 +130,7 @@ static int a9m2440_devices_init(void)
> writel(reg, S3C_MISCCR);
>
> /* --- the devices the boot loader should work with */
> - add_generic_device("s3c24x0_nand", DEVICE_ID_DYNAMIC, NULL,
> S3C24X0_NAND_BASE, 0,
> -IORESOURCE_MEM, &nand_info);
> + s3c24xx_add_nand(&nand_info);
> /*
>* cs8900 network controller onboard
>* Connected to CS line 5 + A24 and interrupt line EINT9,
> @@ -164,8 +164,7 @@ void __bare_init nand_boot(void)
>
> static int a9m2440_console_init(void)
> {
> - add_generic_device("s3c_serial", DEVICE_ID_DYNAMIC, NULL,
> S3C_UART1_BASE,
> - S3C_UART1_SIZE, IORESOURCE_MEM, NULL);
> + s3c24xx_add_uart1();
> return 0;
> }
>
> diff --git a/arch/arm/boards/mini2440/mini2440.c
> b/arch/arm/boards/mini2440/mini2440.c
> index 3d3b820..3523949 100644
> --- a/arch/arm/boards/mini2440/mini2440.c
> +++ b/arch/arm/boards/mini2440/mini2440.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -297,8 +298,7 @@ static int mini2440_devices_init(void)
> reg |= 0x1;
> writel(reg, S3C_MISCCR);
>
> - add_generic_device("s3c24x0_nand", DEVICE_ID_DYNAMIC, NULL,
> S3C24X0_NAND_BASE,
> - 0, IORESOURCE_MEM, &nand_info);
> + s3c24xx_add_nand(&nand_info);
>
> add_dm9000_device(0, S3C_CS4_BASE + 0x300, S3C_CS4_BASE + 0x304,
> IORESOURCE_MEM_16BIT, &dm9000_data);
> @@ -312,12 +312,9 @@ static int mini2440_devices_init(void)
> devfs_add_partition("nand0", 0x4, 0x2, DEVFS_PARTITION_FIXED,
> "env_raw");
> dev_add_bb_dev("env_raw", "env0");
> #endif
> - add_generic_device("s3c_mci", 0, NULL, S3C2410_SDI_BASE, 0,
> -IORESOURCE_MEM, &mci_data);
> - add_generic_device("s3c_fb", 0, NULL, S3C2410_LCD_BASE, 0,
> -IORESOURCE_MEM, &s3c24x0_fb_data);
> - add_generic_device("ohci", 0, NULL, S3C2410_USB_HOST_BASE, 0x100,
> -IORESOURCE_MEM, NULL);
> + s3c24xx_add_mci(&mci_data);
> + s3c24xx_add_fb(&s3c24x0_fb_data);
> + s3c24xx_add_ohci();
> armlinux_set_bootparams((void*)S3C_SDRAM_BASE + 0x100);
> armlinux_set_architecture(MACH_TYPE_MINI2440);
>
> @@ -344,8 +341,7 @@ static int mini2440_console_init(void)
> s3c_gpio_mode(GPH2_TXD0);
> s3c_gpio_mode(GPH3_RXD0);
>
> - add_generic_device("s3c_serial", DEVICE_ID_DYNAMIC, NULL,
> S3C_UART1_BASE,
> - S3C_UART1_SIZE, IORESOURCE_MEM, NULL);
> +
Re: [PATCH 11/18] ARM/Samsung: add generic lowlevel init
On Fri, Jul 13, 2012 at 09:01:03PM +0200, Juergen Beisert wrote: > Just a placeholder for some required low level routines > --- > arch/arm/mach-samsung/Makefile |1 + > arch/arm/mach-samsung/lowlevel-s3c64xx.c | 14 ++ > 2 files changed, 15 insertions(+) > create mode 100644 arch/arm/mach-samsung/lowlevel-s3c64xx.c Please just drop this one. Sascha > > diff --git a/arch/arm/mach-samsung/Makefile b/arch/arm/mach-samsung/Makefile > index 091b600..ac34d86 100644 > --- a/arch/arm/mach-samsung/Makefile > +++ b/arch/arm/mach-samsung/Makefile > @@ -1,5 +1,6 @@ > obj-y += s3c-timer.o generic.o > obj-lowlevel-$(CONFIG_ARCH_S3C24xx) += lowlevel-s3c24x0.o > +obj-lowlevel-$(CONFIG_ARCH_S3C64xx) += lowlevel-s3c64x0.o > obj-lowlevel-$(CONFIG_ARCH_S5PCxx) += lowlevel-s5pcxx.o > obj-$(CONFIG_ARCH_S3C24xx) += gpio-s3c24x0.o clocks-s3c24xx.o mem-s3c24x0.o > obj-$(CONFIG_ARCH_S5PCxx) += gpio-s5pcxx.o clocks-s5pcxx.o mem-s5pcxx.o > diff --git a/arch/arm/mach-samsung/lowlevel-s3c64xx.c > b/arch/arm/mach-samsung/lowlevel-s3c64xx.c > new file mode 100644 > index 000..b1ba719 > --- /dev/null > +++ b/arch/arm/mach-samsung/lowlevel-s3c64xx.c > @@ -0,0 +1,14 @@ > +/* > + * Copyright (C) 2012 Juergen Beisert > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > -- > 1.7.10.4 > > > ___ > barebox mailing list > barebox@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/barebox > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Atmel AT91 SD/MMC clock too fast
Due to integer truncation, the calculated divisor for the SD/MMC clock may
be too low, resulting in a clock that is too fast. For example, the
at91sam9g45 is typically run with a master clock at 133 MHz. There is no
divisor possible that will result in a 25 or 50 MHz clock as is typically
used for a SD card. The existing code will set the clock at 33 MHz or 66 MHz
when 25 or 50 MHz is requested. A Kingston class 10 8G SDHC was found to not
work properly at 33 MHz, but did after patching. The patch, in this case,
generated a 22.1 MHz clock ( 133/6 ). This is the same frequency that this
card sees after booting Linux. If a perfect integer division is possible,
the patch will provide an exact clock rate. If not, the frequency will be
the closest possible without exceeding the target.
The following was based on barebox 2012-07:
--- a/drivers/mci/atmel_mci.c 2012-07-02 01:31:52.0 -0700
+++ b/drivers/mci/atmel_mci.c 2012-07-15 23:14:02.203872596 -0700
@@ -76,7 +76,8 @@
unsigned int clk_in = clk_get_rate(host->clk);
if (clk_ios > 0) {
- divider = (clk_in / clk_ios) / 2;
+ /* don't allow integer truncation to result in too small a
divider */
+ divider = (clk_in + 2 * clk_ios - 1) / (2 * clk_ios);
if (divider > 0)
divider -= 1;
}
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 05/18] Samsung/serial: make the clock source configureable
On Fri, Jul 13, 2012 at 09:00:57PM +0200, Juergen Beisert wrote:
> Instead of taking the value from somewhere, use the menu to select one. Also
> provide sane default values for known SoCs.
Do we really really need this in Kconfig? I don't like having things in
Kconfig which decide between 'right' and 'wrong'. You should rather have
some cpu_is or platformdata mechanism.
Sascha
>
> Signed-off-by: Juergen Beisert
> ---
> drivers/serial/Kconfig | 12
> drivers/serial/serial_s3c.c |7 +--
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index a9383da..a118aaf 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -85,6 +85,18 @@ config DRIVER_SERIAL_S3C
> help
> Say Y here if you want to use the CONS on a Samsung S3C CPU
>
> +config DRIVER_SERIAL_S3C_CLK
> + int
> + prompt "input clock reference"
> + depends on DRIVER_SERIAL_S3C
> + default 0 if ARCH_S3C24xx
> + default 3 if ARCH_S5PCxx
> + help
> + Select one of up to four available clock sources for the UART:
> +0+1: PCLK, 2: UCLK0, 3: UCLK1
> + Note: not all values are possible on all Samsung SoCs. Read the
> + manual if unsure.
> +
> config DRIVER_SERIAL_S3C_AUTOSYNC
> bool "Enable auto flow"
> depends on DRIVER_SERIAL_S3C
> diff --git a/drivers/serial/serial_s3c.c b/drivers/serial/serial_s3c.c
> index ff3792b..5c05ba8 100644
> --- a/drivers/serial/serial_s3c.c
> +++ b/drivers/serial/serial_s3c.c
> @@ -47,11 +47,6 @@
> # define UINTM 0x38 /* interrupt mask register */
> #endif
>
> -#ifndef S3C_UART_CLKSEL
> -/* Use pclk */
> -# define S3C_UART_CLKSEL 0
> -#endif
> -
> struct s3c_uart {
> void __iomem *regs;
> struct console_device cdev;
> @@ -108,7 +103,7 @@ static int s3c_serial_init_port(struct console_device
> *cdev)
>
> /* tx=level,rx=edge,disable timeout int.,enable rx error int.,
>* normal, interrupt or polling, no pre-divider */
> - writew(0x0245 | ((S3C_UART_CLKSEL) << 10), base + UCON);
> + writew(0x0245 | ((CONFIG_DRIVER_SERIAL_S3C_CLK) << 10), base + UCON);
>
> #ifdef S3C_UART_HAS_UINTM
> /* 'interrupt or polling mode' for both directions */
> --
> 1.7.10.4
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 02/18] ARM/Samsung: unify device registration for the S3C24XX SoCs
Sascha Hauer wrote: > On Fri, Jul 13, 2012 at 09:00:54PM +0200, Juergen Beisert wrote: > > Barebox crashes since it has trouble with a resource size of 0. Most of > > the S3C24XX based platforms crashes at runtime and can't use devices with > > resource sizes of 0 anymore. This patch fix it by unifying the device > > registration for all current Barebox's S3C24XX based platforms. > > > > - A9M2410 and A9M2440 compile time tested only. > > - Mini2440 also runtime tested. > > So this is stuff for master, right? Hmm, yes. :) jbe -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-5121-206917-5128 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/5] imx_fec: Allow driver clients to supply MAC address
On Mon, Jul 16, 2012 at 11:04:55AM +1000, Marc Reilly wrote:
> This patch adds a handler to the fec platform data to get MAC address.
> If a handler is not specified the driver uses the existing one.
We already have a generic mechanism for that. See eth_register_ethaddr.
If you pass a MAC address to this function this one will be used instead
of the default one from the driver.
Sascha
>
> Signed-off-by: Marc Reilly
> ---
> drivers/net/fec_imx.c |6 +-
> include/fec.h |4
> 2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec_imx.c b/drivers/net/fec_imx.c
> index 599a9b4..5084758 100644
> --- a/drivers/net/fec_imx.c
> +++ b/drivers/net/fec_imx.c
> @@ -629,10 +629,14 @@ static int fec_probe(struct device_d *dev)
> edev->send = fec_send;
> edev->recv = fec_recv;
> edev->halt = fec_halt;
> - edev->get_ethaddr = fec_get_hwaddr;
> edev->set_ethaddr = fec_set_hwaddr;
> edev->parent = dev;
>
> + if (pdata->get_hwaddr)
> + edev->get_ethaddr = pdata->get_hwaddr;
> + else
> + edev->get_ethaddr = fec_get_hwaddr;
> +
> fec->regs = dev_request_mem_region(dev, 0);
>
> /* Reset chip. */
> diff --git a/include/fec.h b/include/fec.h
> index f56b023..5072bbf 100644
> --- a/include/fec.h
> +++ b/include/fec.h
> @@ -36,6 +36,8 @@ typedef enum {
> RGMII,
> } xceiver_type;
>
> +struct eth_device;
> +
> /*
> * Define the phy connected externally for FEC drivers
> * (like MPC52xx and i.MX27)
> @@ -43,6 +45,8 @@ typedef enum {
> struct fec_platform_data {
> xceiver_type xcv_type;
> int phy_addr;
> +
> + int (*get_hwaddr)(struct eth_device *dev, unsigned char *mac);
> };
>
> #endif /* __INCLUDE_NETWORK_FEC_H */
> --
> 1.7.7
>
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 4/5] at24: add I2C eeprom for 24cl02
On Mon, Jul 16, 2012 at 11:04:58AM +1000, Marc Reilly wrote:
> This series adds a driver for at24 eeproms. Much of the guts of the code
> is taken from the at24 driver in the linux kernel.
>
> Signed-off-by: Marc Reilly
> ---
> drivers/eeprom/Kconfig |7 +++
> drivers/eeprom/Makefile |1 +
> drivers/eeprom/at24.c | 134
> +++
> 3 files changed, 142 insertions(+), 0 deletions(-)
> create mode 100644 drivers/eeprom/at24.c
>
> diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
> index a0b5489..56dfd1a 100644
> --- a/drivers/eeprom/Kconfig
> +++ b/drivers/eeprom/Kconfig
> @@ -8,4 +8,11 @@ config EEPROM_AT25
> after you configure the board init code to know about each eeprom
> on your target board.
>
> +config EEPROM_AT24
> + bool "at24 based eeprom"
> + depends on I2C
> + help
> + Provides read/write for the at24 family of I2C EEPROMS.
> + Currently only the 2K bit versions are supported.
> +
Trailing whitespace here.
> +{
> + struct at24 *priv = to_at24(cdev);
> + const u8 *buf = _buf;
> + const int maxwrite = 8;
> + int numtowrite;
> + ssize_t numwritten = 0;
> +
> + while (count) {
> + int ret;
> +
> + numtowrite = count;
> + if (numtowrite > maxwrite)
> + numtowrite = maxwrite;
> +
> + ret = i2c_write_reg(priv->client, offset, buf, numtowrite);
> + if (ret < 0)
> + return (ssize_t)ret;
> +
> + mdelay(10);
Do we need this? This makes the driver veeery slow. If we could poll
this somehow it would be much better.
> +
> +static int at24_init(void)
> +{
> + register_driver(&at24_driver);
> + return 0;
We can safely return the result of register_driver here. There was a
time when barebox paniced on a failed initcall, but this is not the case
anymore. Instead we have some debug output for failed initcalls which
seems more useful
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v2] usb: gadget: enable for MXS
Signed-off-by: Marc Kleine-Budde --- Changes since v1: - enable Arc OTG Driver, too (tnx Sascha) Marc drivers/usb/gadget/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index f7f2697..465121c 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -4,7 +4,7 @@ menuconfig USB_GADGET config USB_HAVE_GADGET_DRIVER bool - default y if ARCH_IMX || ARCH_AT91 || ARCH_PXA + default y if ARCH_IMX || ARCH_MXS || ARCH_AT91 || ARCH_PXA if USB_GADGET @@ -17,7 +17,7 @@ choice config USB_GADGET_DRIVER_ARC bool prompt "Arc OTG device core" - depends on ARCH_IMX + depends on ARCH_IMX || ARCH_MXS select USB_GADGET_DUALSPEED select POLLER -- 1.7.10.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Atmel AT91 SD/MMC clock too fast
Hi George,
On Mon, Jul 16, 2012 at 12:22:13AM -0700, George Pontis wrote:
> Due to integer truncation, the calculated divisor for the SD/MMC clock may
> be too low, resulting in a clock that is too fast. For example, the
> at91sam9g45 is typically run with a master clock at 133 MHz. There is no
> divisor possible that will result in a 25 or 50 MHz clock as is typically
> used for a SD card. The existing code will set the clock at 33 MHz or 66 MHz
> when 25 or 50 MHz is requested. A Kingston class 10 8G SDHC was found to not
> work properly at 33 MHz, but did after patching. The patch, in this case,
> generated a 22.1 MHz clock ( 133/6 ). This is the same frequency that this
> card sees after booting Linux. If a perfect integer division is possible,
> the patch will provide an exact clock rate. If not, the frequency will be
> the closest possible without exceeding the target.
>
> The following was based on barebox 2012-07:
>
> --- a/drivers/mci/atmel_mci.c 2012-07-02 01:31:52.0 -0700
> +++ b/drivers/mci/atmel_mci.c 2012-07-15 23:14:02.203872596 -0700
> @@ -76,7 +76,8 @@
> unsigned int clk_in = clk_get_rate(host->clk);
>
> if (clk_ios > 0) {
> - divider = (clk_in / clk_ios) / 2;
> + /* don't allow integer truncation to result in too small a
> divider */
> + divider = (clk_in + 2 * clk_ios - 1) / (2 * clk_ios);
DIV_ROUND_UP(clk_in, clk_ios / 2) instead?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/4] Enable a way to provide the reason for "being here"
On Fri, Jul 13, 2012 at 08:04:46AM +0200, Juergen Beisert wrote: > Many architectures support a way to detect why the bootloader is running. > This patch adds a global variable to be able to use the cause in some kind of > shell code to do special things on demand. For example to do an emergency > boot, > when the last boot fails and the watchdog reactivate the hanging system. > > Signed-off-by: Juergen Beisert > --- > common/Makefile|2 +- > common/reset_source.c | 44 > include/reset_source.h | 27 +++ > 3 files changed, 72 insertions(+), 1 deletion(-) > create mode 100644 common/reset_source.c > create mode 100644 include/reset_source.h > > diff --git a/common/Makefile b/common/Makefile > index d99dfa2..baf4539 100644 > --- a/common/Makefile > +++ b/common/Makefile > @@ -29,7 +29,7 @@ obj-$(CONFIG_UIMAGE) += uimage.o > obj-y += startup.o > obj-y += misc.o > obj-y += memsize.o > -obj-$(CONFIG_GLOBALVAR) += globalvar.o > +obj-$(CONFIG_GLOBALVAR) += globalvar.o reset_source.o This should be a separate config option which depends on GLOBALVAR. > + RESET_WKE, /* wake-up (some SoCs can handle this) */ > + RESET_JTAG, /* JTAG reset */ > +}; > + > +extern void set_reset_source(enum reset_src_type); 'extern' is not needed in function declarations. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
barebox image size
hi, we need to implement a lot of features into the barebox. Finally the size of the image will be bigger than the standard max of 256K. When i flash an image, bigger than 256K to nand, barebox does not boot anymore - if i reduce it to 256K or smaller, everthing works fine. What do i have to do to use a bigger barebox image size? - christian___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: barebox image size
On Mon, Jul 16, 2012 at 10:37:41AM +0200, christian.buett...@rafi.de wrote: > hi, > > we need to implement a lot of features into the barebox. Finally the size > of the image will be bigger than the standard max of 256K. > When i flash an image, bigger than 256K to nand, barebox does not boot > anymore - if i reduce it to 256K or smaller, everthing works fine. > > What do i have to do to use a bigger barebox image size? Just a guess: You are using imx_nand_load_image() with a fixed size of 256k. grep for this function in the current tree and see how the correct image size is calculated. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: AT91SAM9263-EK
On Fri, Jul 13, 2012 at 11:35:39AM +0200, Stutz Sven wrote: > Hello everybody, > > > But everything without success. It's a little bit strange because > when I execute the command > bootm -v /dev/nand0.kernel.bb > First I get the following output > Barebox:/ bootm -v /dev/nand0.kernel.bb > Image Name: Linux-3.4.0 > OS: Linux > Architecture: ARM > Type: Kernel Image > Compression:uncompressed > Data Size: 2034784 Bytes = 1.9 MB > Load Address:20008000 > Entry Point:20008000 > err -74 > loading os image failed with Out of memory > > and if I try again the same command > Barebox:/ bootm -v /dev/nand0.kernel.bb > err -74 > Unknown OS filetype (try -f) > > also if I try to memcpy or uimage I always get this err 74. > > What is this Error 74 (-- Reset level 3)? -74 is EBADMSG, see include/asm-generic/errno.h. The nand driver throws this when it can't read due to ecc errors. Something seems wrong with your nand driver. I remember Jean-Christophe mentioned that the atmel nand support is currently broken. Could you please try if either: - barebox v2012.07.0 or - current master works for you? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Antwort: Re: barebox image size
i am using:
static inline struct device_d *imx53_add_nand(struct
imx_nand_platform_data *pdata)
{
struct resource res[] = {
{
.start = MX53_NFC_BASE_ADDR,
.size = SZ_4K,
.flags = IORESOURCE_MEM,
}, {
.start = MX53_NFC_AXI_BASE_ADDR,
.size = SZ_4K,
.flags = IORESOURCE_MEM,
},
};
struct device_d *dev = xzalloc(sizeof(*dev));
dev->resource = xzalloc(sizeof(struct resource) *
ARRAY_SIZE(res));
memcpy(dev->resource, res, sizeof(struct resource) *
ARRAY_SIZE(res));
dev->num_resources = ARRAY_SIZE(res);
strcpy(dev->name, "imx_nand");
dev->id = -1;
dev->platform_data = pdata;
register_device(dev);
return dev;
}
with imx_nand_platform_data parameter:
static struct imx_nand_platform_data tx53_nand_pdata =
{
.width = 1,
.hw_ecc = 1,
.flash_bbt = 1,
};
imx_nand_load_image() is never used in my imx53 board init code.. is this
the fault?
- christian
Von:Sascha Hauer
An: christian.buett...@rafi.de,
Kopie: barebox@lists.infradead.org
Datum: 16.07.2012 10:54
Betreff:Re: barebox image size
On Mon, Jul 16, 2012 at 10:37:41AM +0200, christian.buett...@rafi.de
wrote:
> hi,
>
> we need to implement a lot of features into the barebox. Finally the
size
> of the image will be bigger than the standard max of 256K.
> When i flash an image, bigger than 256K to nand, barebox does not boot
> anymore - if i reduce it to 256K or smaller, everthing works fine.
>
> What do i have to do to use a bigger barebox image size?
Just a guess:
You are using imx_nand_load_image() with a fixed size of 256k. grep for
this function in the current tree and see how the correct image size is
calculated.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: barebox image size
Hi Christian, Le Mon, 16 Jul 2012 11:15:24 +0200, christian.buett...@rafi.de a écrit : > imx_nand_load_image() is never used in my imx53 board init code.. is this > the fault? > FWIW I had the same issue on an i.MX51 : I didn't yet had the time to investigate. Eric ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Antwort: Re: barebox image size
On Mon, Jul 16, 2012 at 11:15:24AM +0200, christian.buett...@rafi.de wrote:
>
> imx_nand_load_image() is never used in my imx53 board init code.. is this
> the fault?
>
On i.MX53 there might be a similar issue. You probably have something
like this in your board:
struct imx_flash_header_v2 __flash_header_section flash_header = {
.header.tag = IVT_HEADER_TAG,
.header.length = cpu_to_be16(32),
.header.version = IVT_VERSION,
.entry = APP_DEST + 0x1000,
.dcd_ptr= APP_DEST + 0x400 + offsetof(struct
imx_flash_header_v2, dcd),
.boot_data_ptr = APP_DEST + 0x400 + offsetof(struct
imx_flash_header_v2, boot_data),
.self = APP_DEST + 0x400,
.boot_data.start= APP_DEST,
.boot_data.size = DCD_BAREBOX_SIZE,
.boot_data.size is the interesting field. What do you have here?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Antwort: Re: Antwort: Re: barebox image size
here it is:
struct imx_flash_header_v2 __flash_header_section flash_header =
{
.header.tag = IVT_HEADER_TAG,
.header.length = cpu_to_be16(32),
.header.version = IVT_VERSION,
.entry = APP_DEST + 0x1000,
.dcd_ptr= APP_DEST + 0x400 + offsetof(struct
imx_flash_header_v2, dcd),
.boot_data_ptr = APP_DEST + 0x400 + offsetof(struct
imx_flash_header_v2, boot_data),
.self = APP_DEST + 0x400,
.boot_data.start= APP_DEST,
.boot_data.size = 0x4,
.dcd.header.tag = DCD_HEADER_TAG,
.dcd.header.length = cpu_to_be16(sizeof(struct imx_dcd) +
sizeof(dcd_entry)),
.dcd.header.version = DCD_VERSION,
.dcd.command.tag= DCD_COMMAND_WRITE_TAG,
.dcd.command.length = cpu_to_be16(sizeof(struct imx_dcd_command) +
sizeof(dcd_entry)),
.dcd.command.param = DCD_COMMAND_WRITE_PARAM,
};
there is another struct:
struct imx_fcb_header __flash_header_fcb fcb_entry =
{
.fcb_marker = 0x20424346,
.fcb_version = 0x01,
.st_pg_prm = 0x0,
.st_pg_sec = 0x0,
.reserved3[0] = 0x6b,
.reserved3[1] = 0x6b,
.st_pg_dbbt = 0x0,
.bbm_off_main = 0x0,
.bi_swap = 0x0,
.bbm_off_spare = 0x0,
};
Von:Sascha Hauer
An: christian.buett...@rafi.de,
Kopie: barebox@lists.infradead.org
Datum: 16.07.2012 11:21
Betreff:Re: Antwort: Re: barebox image size
On Mon, Jul 16, 2012 at 11:15:24AM +0200, christian.buett...@rafi.de
wrote:
>
> imx_nand_load_image() is never used in my imx53 board init code.. is
this
> the fault?
>
On i.MX53 there might be a similar issue. You probably have something
like this in your board:
struct imx_flash_header_v2 __flash_header_section flash_header = {
.header.tag = IVT_HEADER_TAG,
.header.length =
cpu_to_be16(32),
.header.version =
IVT_VERSION,
.entry =
APP_DEST + 0x1000,
.dcd_ptr= APP_DEST +
0x400 + offsetof(struct imx_flash_header_v2, dcd),
.boot_data_ptr = APP_DEST +
0x400 + offsetof(struct imx_flash_header_v2, boot_data),
.self =
APP_DEST + 0x400,
.boot_data.start= APP_DEST,
.boot_data.size =
DCD_BAREBOX_SIZE,
.boot_data.size is the interesting field. What do you have here?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/2] tx51: ensure eth phy resets properly by driving reset pin explicitly.
diff --git a/arch/arm/boards/karo-tx51/tx51.c b/arch/arm/boards/karo-tx51/tx51.c index 096683a..d862a68 100644 --- a/arch/arm/boards/karo-tx51/tx51.c +++ b/arch/arm/boards/karo-tx51/tx51.c @@ -205,6 +205,12 @@ static inline void tx51_fec_init(void) } /* +*Turn off phy power, be cautious and wait +*/ + gpio_set_value(TX51_FEC_PHY_PWR, 0); + mdelay(20); + + /* *Turn on phy power, leave in reset state */ gpio_set_value(TX51_FEC_PHY_PWR, 1); @@ -212,7 +218,7 @@ static inline void tx51_fec_init(void) /* * Wait some time to let the phy activate the internal regulator */ - mdelay(10); + mdelay(20); /* * Deassert reset, phy latches the rest of bootstrap pins -- 1.7.5.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/2] tx51: Disable kallsyms. It prevents the board from booting.
diff --git a/arch/arm/configs/tx51stk5_defconfig b/arch/arm/configs/tx51stk5_defconfig index 7fff0f0..e1796b9 100644 --- a/arch/arm/configs/tx51stk5_defconfig +++ b/arch/arm/configs/tx51stk5_defconfig @@ -32,7 +32,6 @@ CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y CONFIG_HAVE_CONFIGURABLE_MEMORY_LAYOUT=y CONFIG_MEMORY_LAYOUT_DEFAULT=y CONFIG_MALLOC_TLSF=y -CONFIG_KALLSYMS=y CONFIG_LONGHELP=y CONFIG_SHELL_HUSH=y CONFIG_GLOB=y -- 1.7.5.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 0/2] Misc Karo TX51 fixes
The Karo TX51 port in the master tree is currently not booting. These patches fix it by removing the 'kallsyms' config option. Another issue fixed is unreliable resetting of the ethernet phy chip. Christian Kapeller (2): tx51: ensure eth phy resets properly by driving reset pin explicitly. tx51: Disable kallsyms. It prevents the board from booting. arch/arm/boards/karo-tx51/tx51.c|8 +++- arch/arm/configs/tx51stk5_defconfig |1 - 2 files changed, 7 insertions(+), 2 deletions(-) -- 1.7.5.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Antwort: Re: Antwort: Re: barebox image size
On Mon, Jul 16, 2012 at 11:37:59AM +0200, christian.buett...@rafi.de wrote:
> here it is:
>
> struct imx_flash_header_v2 __flash_header_section flash_header =
> {
> .header.tag = IVT_HEADER_TAG,
> .header.length = cpu_to_be16(32),
> .header.version = IVT_VERSION,
>
> .entry = APP_DEST + 0x1000,
> .dcd_ptr= APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, dcd),
> .boot_data_ptr = APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, boot_data),
> .self = APP_DEST + 0x400,
>
> .boot_data.start= APP_DEST,
> .boot_data.size = 0x4,
And here you have the magic 256k. Please use DCD_BAREBOX_SIZE instead.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
tx51 ethernet regression
Hi, I recently came to update my barebox port based on the karo tx51 imx module from v2012.03.0 to v2012.07.0. I discovered, that, when trying to use the ethernet connection, I more often than not get frame errors reported by the FEC. --snip-- barebox@Ka-Ro tx51:/ dhcp phy0: Link is up - 1000/Full error frame: 0x97b961c0 0x0890 error frame: 0x97b96188 0x0882 DHCP client bound to address 10.41.14.147 --snap-- The errors range from 'non octet aligned frame' over 'Fifo overrun' to timeouts. It renders the ethernet support unusable. Small images may work but, require the one and other retry. One thing that catches my eye is that the auto negotioation resulted in a 1000MBit link. The imx fec does only support 100MBit. I forced the link to be set to 10MBit by declaring xcv_type=MII10 in the fec_platform_data structure. Interestingly the link is now reported as 100MBit, and shows the same behaviour. Another thing I checked was the changed pad definitions in commit 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad data structure changed, but also some of their configuration as well. For example, pads that were configured with FEC_PAD_CTL, now have other settings enabled. I'reverted the pad changes, but still no luck. Auto negtiation starts, but I don't seem to get any packets. So my question is: What change since v2012.03.0 could cause this kind of behaviour? Regards Christian -- Christian Kapeller cmotion GmbH Kriehubergasse 16 1050 Wien / Austria http://www.cmotion.eu christian.kapel...@cmotion.eu Phone: +43 1 789 1096 38 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 2/2] input: add i.MX51 platform code for matrix keypad driver
diff --git a/arch/arm/mach-imx/devices.c b/arch/arm/mach-imx/devices.c
index 6cd50f3..8120f56 100644
--- a/arch/arm/mach-imx/devices.c
+++ b/arch/arm/mach-imx/devices.c
@@ -52,3 +52,8 @@ struct device_d *imx_add_esdhc(void *base, int id, struct
esdhc_platform_data *p
{
return imx_add_device("imx-esdhc", id, base, 0x1000, pdata);
}
+
+struct device_d *imx_add_kpp(void *base, struct matrix_keymap_data *pdata)
+{
+ return imx_add_device("imx-kpp", -1, base, 0x1000, pdata);
+}
diff --git a/arch/arm/mach-imx/include/mach/devices-imx51.h
b/arch/arm/mach-imx/include/mach/devices-imx51.h
index dbf5862..3d7ff72 100644
--- a/arch/arm/mach-imx/include/mach/devices-imx51.h
+++ b/arch/arm/mach-imx/include/mach/devices-imx51.h
@@ -89,3 +89,7 @@ static inline struct device_d *imx51_add_nand(struct
imx_nand_platform_data *pda
return dev;
}
+static inline struct device_d *imx51_add_kpp(struct matrix_keymap_data *pdata)
+{
+ return imx_add_kpp((void *)MX51_KPP_BASE_ADDR, pdata);
+}
diff --git a/arch/arm/mach-imx/include/mach/devices.h
b/arch/arm/mach-imx/include/mach/devices.h
index f0f730a..da91646 100644
--- a/arch/arm/mach-imx/include/mach/devices.h
+++ b/arch/arm/mach-imx/include/mach/devices.h
@@ -1,5 +1,6 @@
#include
+#include
#include
#include
#include
@@ -16,4 +17,5 @@ struct device_d *imx_add_fb(void *base, struct
imx_fb_platform_data *pdata);
struct device_d *imx_add_ipufb(void *base, struct imx_ipu_fb_platform_data
*pdata);
struct device_d *imx_add_mmc(void *base, int id, void *pdata);
struct device_d *imx_add_esdhc(void *base, int id, struct esdhc_platform_data
*pdata);
+struct device_d *imx_add_kpp(void *base, struct matrix_keymap_data *pdata);
--
1.7.5.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 0/2] imx: add matrix keypad (kpp) input driver
This patchset adds support for the imx matrix keypad peripheral (kpp). I've fleshed out the linux keypad driver, and remodeled it after the gpio_keys driver. Currently platform helper functions are only provided for the imx51. Christian Kapeller (2): input: Add i.MX matrix keypad driver input: add i.MX51 platform code for matrix keypad driver arch/arm/mach-imx/devices.c|5 + arch/arm/mach-imx/include/mach/devices-imx51.h |4 + arch/arm/mach-imx/include/mach/devices.h |2 + drivers/input/Kconfig | 13 + drivers/input/Makefile |1 + drivers/input/imx_keypad.c | 463 include/matrix_keypad.h| 59 +++ 7 files changed, 547 insertions(+), 0 deletions(-) create mode 100644 drivers/input/imx_keypad.c create mode 100644 include/matrix_keypad.h -- 1.7.5.4 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH 1/2] input: Add i.MX matrix keypad driver
create mode 100644 drivers/input/imx_keypad.c
create mode 100644 include/matrix_keypad.h
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index b488553..a5aec03 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -16,4 +16,17 @@ config KEYBOARD_GPIO
setup logic must also provide a platform device,
with configuration data saying which GPIOs are used.
+config KEYBOARD_IMX_KEYPAD
+ bool "IMX Keypad"
+ depends on ARCH_IMX
+ select POLLER
+ help
+ This driver implements support for buttons connected
+ to the IMX keypad matrix.
+
+ Say Y here if your device has buttons connected
+ to the IMX keypad matrix. Your board-specific
+ setup logic must also provide a 'matrix_keymap_data' structure,
+ defining the used keys.
+
endmenu
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 7784d52..3d105cc 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_KEYBOARD_GPIO) += gpio_keys.o
+obj-$(CONFIG_KEYBOARD_IMX_KEYPAD) += imx_keypad.o
diff --git a/drivers/input/imx_keypad.c b/drivers/input/imx_keypad.c
new file mode 100644
index 000..bd9c6dc
--- /dev/null
+++ b/drivers/input/imx_keypad.c
@@ -0,0 +1,463 @@
+/*
+ * Driver for the IMX keypad port.
+ * Copyright (C) 2009 Alberto Panizzo
+ * Copyright (C) 2012 Christian Kapeller
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+/*
+ To use the imx keypad driver, you have to define the keys in your
platform
+ code.
+
+ 1. Configure the imx keypad row & column pads used by your board
+ 2. Define the keys you want to use:
+
+ #define BTN_1 0x101
+ #define BTN_2 0x102
+ #define BTN_3 0x103
+
+ static uint32_t keypad_codes[] = {
+ // specify your keymap with KEY(row, col, keycode)
+ KEY(0, 1, BTN_1),
+ KEY(1, 0, BTN_2),
+ KEY(1, 1, BTN_3),
+ };
+
+ static struct matrix_keymap_data keypad_data = {
+ .keymap = keypad_codes,
+ .keymap_size = ARRAY_SIZE(keypad_codes),
+ };
+
+ 3. Add the keypad to your platform in your devices init callback:
+
+ imx51_add_kpp(&keypad_data);
+
+ 4. Compile , flash, and enjoy
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Keypad Controller registers (halfword)
+ */
+#define KPCR 0x00 /* Keypad Control Register */
+
+#define KPSR 0x02 /* Keypad Status Register */
+#define KBD_STAT_KPKD (0x1 << 0) /* Key Press Interrupt Status bit (w1c) */
+#define KBD_STAT_KPKR (0x1 << 1) /* Key Release Interrupt Status bit (w1c) */
+#define KBD_STAT_KDSC (0x1 << 2) /* Key Depress Synch Chain Status bit (w1c)*/
+#define KBD_STAT_KRSS (0x1 << 3) /* Key Release Synch Status bit (w1c)*/
+#define KBD_STAT_KDIE (0x1 << 8) /* Key Depress Interrupt Enable Status bit */
+#define KBD_STAT_KRIE (0x1 << 9) /* Key Release Interrupt Enable */
+#define KBD_STAT_KPPEN (0x1 << 10) /* Keypad Clock Enable */
+
+#define KDDR 0x04 /* Keypad Data Direction Register */
+#define KPDR 0x06 /* Keypad Data Register */
+
+#define MAX_MATRIX_KEY_ROWS8
+#define MAX_MATRIX_KEY_COLS8
+#define MATRIX_ROW_SHIFT 3
+
+#define MAX_MATRIX_KEY_NUM (MAX_MATRIX_KEY_ROWS * MAX_MATRIX_KEY_COLS)
+
+struct imx_keypad {
+ struct clk *clk;
+ struct device_d *dev;
+ struct console_device cdev;
+ void __iomem *mmio_base;
+
+ /* optional */
+ int fifo_size;
+
+ struct kfifo *recv_fifo;
+ struct poller_struct poller;
+
+ /*
+* The matrix is stable only if no changes are detected after
+* IMX_KEYPAD_SCANS_FOR_STABILITY scans
+*/
+#define IMX_KEYPAD_SCANS_FOR_STABILITY 3
+ int stable_count;
+
+ /* Masks for enabled rows/cols */
+ unsigned short rows_en_mask;
+ unsigned short cols_en_mask;
+
+ unsigned short keycodes[MAX_MATRIX_KEY_NUM];
+
+ /*
+* Matrix states:
+* -stable: achieved after a complete debounce process.
+* -unstable: used in the debouncing process.
+*/
+ unsigned short matrix_stable_state[MAX_MATRIX_KEY_COLS];
+ unsigned short matrix_unstable_state[MAX_MATRIX_KEY_COLS];
+};
+
+static inline struct imx_keypad *
+poller_to_imx_kp_pdata(struct poller_struct *poller)
+{
+ return container_of(poller, struct imx_keypad, poller);
+}
+
+static inline struct imx_keypad *
+cdev_to_imx_kp_pdata(struct console_device *cdev)
+{
+ return container_of(cdev, struct imx_keypad, cdev);
+}
+
+static int imx_keypad_tstc(struct console_device *cdev)
+{
+
Re: tx51 ethernet regression
Hi Christian, Le Mon, 16 Jul 2012 13:28:13 +0200, Christian Kapeller a écrit : > I recently came to update my barebox port based on the karo tx51 imx > module from v2012.03.0 to v2012.07.0. > > I discovered, that, when trying to use the ethernet connection, I more > often than not get frame errors reported by the FEC. > > --snip-- > barebox@Ka-Ro tx51:/ dhcp > phy0: Link is up - 1000/Full > error frame: 0x97b961c0 0x0890 > error frame: 0x97b96188 0x0882 > DHCP client bound to address 10.41.14.147 > --snap-- > > The errors range from 'non octet aligned frame' over 'Fifo overrun' to > timeouts. It renders the ethernet support unusable. Small images may > work but, require the one and other retry. > > One thing that catches my eye is that the auto negotioation resulted in > a 1000MBit link. The imx fec does only support 100MBit. I forced the > link to be set to 10MBit by declaring xcv_type=MII10 in the > fec_platform_data structure. Interestingly the link is now reported as > 100MBit, and shows the same behaviour. > > Another thing I checked was the changed pad definitions in commit > 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad > data structure changed, but also some of their configuration as well. > For example, pads that were configured with FEC_PAD_CTL, now have other > settings enabled. > > I'reverted the pad changes, but still no luck. Auto negtiation starts, > but I don't seem to get any packets. > > So my question is: What change since v2012.03.0 could cause this kind of > behaviour? > same problem here. the problem comes from : 68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux header file from kernel" as now most pins have NO_PAD_CTRL which means the pad doesn't get reconfigured and thus some pads to communicate with the FEC are no more working. A dirty workaround to default PAD config is : diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c index 680d260..c21d8a2 100644 --- a/arch/arm/mach-imx/iomux-v3.c +++ b/arch/arm/mach-imx/iomux-v3.c @@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad) if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) __raw_writel(pad_ctrl, base + pad_ctrl_ofs); + else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) + __raw_writel(0, base + pad_ctrl_ofs); return 0; } Eric ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
ok i can boot now! Thank you!
I flashed from 0x0 to 0x7 (image size: 479K).
I flashed the environment image (image size: 3K) from 0x8 to 0xF
and changed the config code from barebox/environs/common/config to:
...
nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)"
...
Barebox can boot now but the startup log says:
barebox 2012.03.0-dirty (Jul 16 2012 - 09:01:01)
Board: i.MX53
eth@eth0: got MAC address from EEPROM: *
nand_get_flash_type: second ID read did not match ef,ef against c0,c0
No NAND device found (-19)!
Malloc space: 0x7df0 -> 0x7fef (size 32 MB)
Stack space : 0x7def8000 -> 0x7df0 (size 32 kB)
Open /dev/env0 No such file or directory
running /env/bin/init...
not found
barebox:/
How can i get the environment loaded?
- christian
Von:Sascha Hauer
An: christian.buett...@rafi.de,
Kopie: barebox@lists.infradead.org
Datum: 16.07.2012 12:30
Betreff:Re: Antwort: Re: Antwort: Re: barebox image size
On Mon, Jul 16, 2012 at 11:37:59AM +0200, christian.buett...@rafi.de
wrote:
> here it is:
>
> struct imx_flash_header_v2 __flash_header_section flash_header =
> {
> .header.tag = IVT_HEADER_TAG,
> .header.length = cpu_to_be16(32),
> .header.version = IVT_VERSION,
>
> .entry = APP_DEST + 0x1000,
> .dcd_ptr= APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, dcd),
> .boot_data_ptr = APP_DEST + 0x400 + offsetof(struct
> imx_flash_header_v2, boot_data),
> .self = APP_DEST + 0x400,
>
> .boot_data.start= APP_DEST,
> .boot_data.size = 0x4,
And here you have the magic 256k. Please use DCD_BAREBOX_SIZE instead.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: tx51 ethernet regression
Hi Eric, thanks for the prompt reply. > Le Mon, 16 Jul 2012 13:28:13 +0200, > Christian Kapeller a écrit : >> I recently came to update my barebox port based on the karo tx51 imx >> module from v2012.03.0 to v2012.07.0. >> >> I discovered, that, when trying to use the ethernet connection, I more >> often than not get frame errors reported by the FEC. >> >> --snip-- >> barebox@Ka-Ro tx51:/ dhcp >> phy0: Link is up - 1000/Full >> error frame: 0x97b961c0 0x0890 >> error frame: 0x97b96188 0x0882 >> DHCP client bound to address 10.41.14.147 >> --snap-- >> >> The errors range from 'non octet aligned frame' over 'Fifo overrun' to >> timeouts. It renders the ethernet support unusable. Small images may >> work but, require the one and other retry. >> >> One thing that catches my eye is that the auto negotioation resulted in >> a 1000MBit link. The imx fec does only support 100MBit. I forced the >> link to be set to 10MBit by declaring xcv_type=MII10 in the >> fec_platform_data structure. Interestingly the link is now reported as >> 100MBit, and shows the same behaviour. >> >> Another thing I checked was the changed pad definitions in commit >> 2bdc9f57a86dff41cfc1f87b644a2e53fdcce2b6. Not only the type of the pad >> data structure changed, but also some of their configuration as well. >> For example, pads that were configured with FEC_PAD_CTL, now have other >> settings enabled. >> >> I'reverted the pad changes, but still no luck. Auto negtiation starts, >> but I don't seem to get any packets. >> >> So my question is: What change since v2012.03.0 could cause this kind of >> behaviour? >> > same problem here. the problem comes from : > 68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux > header file from kernel" > as now most pins have NO_PAD_CTRL which means the pad doesn't get > reconfigured and thus some pads to communicate with the FEC are no more > working. > > A dirty workaround to default PAD config is : > diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c > index 680d260..c21d8a2 100644 > --- a/arch/arm/mach-imx/iomux-v3.c > +++ b/arch/arm/mach-imx/iomux-v3.c > @@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > > if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > __raw_writel(pad_ctrl, base + pad_ctrl_ofs); > + else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > + __raw_writel(0, base + pad_ctrl_ofs); > > return 0; > } I see your problem, and why this patch has solved it. My board also uses some pads, that are declared with NO_PAD_CTRL. I've applied your solution as well, but no luck. I see the same behaviour as before. The fact, that I am, able to do dhcp (even without your change), and sometimes transfer files from some other host, makes me think, that my pad config isn't that broken. May be the problem is in the pad configs, some changed to PAD_CTRL_[2,4,5], some are NO_PAD_CTRL. I don't know how the pad configuration influences pads, that are assigned to some imx peripheral, like the FEC. For example the PAD definition for the pads used for reception is inconsistent: from iomux-mx51.h: #define MX51_PAD_NANDF_D9__FEC_RDATA0 IOMUX_PAD(0x554, 0x16c, 0x12, 0x958, 0, MX51_PAD_CTRL_4) #define MX51_PAD_EIM_EB3__FEC_RDATA1IOMUX_PAD(0x46c, 0x0d8, 3, 0x95c, 0, NO_PAD_CTRL) #define MX51_PAD_EIM_CS2__FEC_RDATA2IOMUX_PAD(0x47c, 0x0e8, 3, 0x960, 0, NO_PAD_CTRL) #define MX51_PAD_EIM_CS3__FEC_RDATA3IOMUX_PAD(0x480, 0x0ec, 3, 0x964, 0, NO_PAD_CTRL) I'd expect all RDATA signals all having the same pad control settings. They don't have, and I't doesn't make a difference, when I set them all to PAD_CTRL_4 as the first one. Regards, Christian ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
> I flashed from 0x0 to 0x7 (image size: 479K). > I flashed the environment image (image size: 3K) from 0x8 to 0xF > and changed the config code from barebox/environs/common/config to: > > ... > nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)" > ... > > Barebox can boot now but the startup log says: > barebox 2012.03.0-dirty (Jul 16 2012 - 09:01:01) > > Board: i.MX53 > eth@eth0: got MAC address from EEPROM: * > nand_get_flash_type: second ID read did not match ef,ef against c0,c0 > No NAND device found (-19)! > Malloc space: 0x7df0 -> 0x7fef (size 32 MB) > Stack space : 0x7def8000 -> 0x7df0 (size 32 kB) > Open /dev/env0 No such file or directory > running /env/bin/init... > not found > barebox:/ > > How can i get the environment loaded? Normally you would issue 'saveenv' which writes the environment to the environment partition. On subsequent boots the environment will be loaded. But the flash device on your board isn't detected by barebox, so you will have to fix the detection first. > nand_get_flash_type: second ID read did not match ef,ef against c0,c0 This line suggests, that the nand flash isn't working property. The line is generated in drivers/mtd/nand/nand_base.c, after reading manufacturer id and chip id two times, and checking them for equality. Not only does your board different values for manufacturer and flash id on first and second read, but they are also the same. manuf id=ef and chip id=ef isn't plausible. Maybe you should check your hardware. Regards Christian ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
Thx for the hint. What i don't understand is that barebox boots from nand but the environement can't.. Von:Christian Kapeller An: christian.buett...@rafi.de, Kopie: Sascha Hauer , barebox@lists.infradead.org Datum: 16.07.2012 15:47 Betreff:Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size > I flashed from 0x0 to 0x7 (image size: 479K). > I flashed the environment image (image size: 3K) from 0x8 to 0xF > and changed the config code from barebox/environs/common/config to: > > ... > nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)" > ... > > Barebox can boot now but the startup log says: > barebox 2012.03.0-dirty (Jul 16 2012 - 09:01:01) > > Board: i.MX53 > eth@eth0: got MAC address from EEPROM: * > nand_get_flash_type: second ID read did not match ef,ef against c0,c0 > No NAND device found (-19)! > Malloc space: 0x7df0 -> 0x7fef (size 32 MB) > Stack space : 0x7def8000 -> 0x7df0 (size 32 kB) > Open /dev/env0 No such file or directory > running /env/bin/init... > not found > barebox:/ > > How can i get the environment loaded? Normally you would issue 'saveenv' which writes the environment to the environment partition. On subsequent boots the environment will be loaded. But the flash device on your board isn't detected by barebox, so you will have to fix the detection first. > nand_get_flash_type: second ID read did not match ef,ef against c0,c0 This line suggests, that the nand flash isn't working property. The line is generated in drivers/mtd/nand/nand_base.c, after reading manufacturer id and chip id two times, and checking them for equality. Not only does your board different values for manufacturer and flash id on first and second read, but they are also the same. manuf id=ef and chip id=ef isn't plausible. Maybe you should check your hardware. Regards Christian ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: tx51 ethernet regression
On Mon, Jul 16, 2012 at 02:52:22PM +0200, Christian Kapeller wrote: > Hi Eric, > > > same problem here. the problem comes from : > > 68b32be4926d3ab5b72036c0ceecef2f82aa0625 "i.MX51: Synchronize iomux > > header file from kernel" > > as now most pins have NO_PAD_CTRL which means the pad doesn't get > > reconfigured and thus some pads to communicate with the FEC are no more > > working. > > > > A dirty workaround to default PAD config is : > > diff --git a/arch/arm/mach-imx/iomux-v3.c b/arch/arm/mach-imx/iomux-v3.c > > index 680d260..c21d8a2 100644 > > --- a/arch/arm/mach-imx/iomux-v3.c > > +++ b/arch/arm/mach-imx/iomux-v3.c > > @@ -45,6 +45,8 @@ int mxc_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > > > > if (!(pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > > __raw_writel(pad_ctrl, base + pad_ctrl_ofs); > > + else if ((pad_ctrl & NO_PAD_CTRL) && pad_ctrl_ofs) > > + __raw_writel(0, base + pad_ctrl_ofs); > > > > return 0; > > } > > I see your problem, and why this patch has solved it. My board also uses > some pads, that are declared with NO_PAD_CTRL. I've applied your > solution as well, but no luck. I see the same behaviour as before. > > The fact, that I am, able to do dhcp (even without your change), and > sometimes transfer files from some other host, makes me think, that my > pad config isn't that broken. May be the problem is in the pad configs, > some changed to PAD_CTRL_[2,4,5], some are NO_PAD_CTRL. > > I don't know how the pad configuration influences pads, that are > assigned to some imx peripheral, like the FEC. For example the PAD > definition for the pads used for reception is inconsistent: > > from iomux-mx51.h: > > #define MX51_PAD_NANDF_D9__FEC_RDATA0 IOMUX_PAD(0x554, 0x16c, 0x12, > 0x958, 0, MX51_PAD_CTRL_4) > #define MX51_PAD_EIM_EB3__FEC_RDATA1 IOMUX_PAD(0x46c, 0x0d8, 3, > 0x95c, > 0, NO_PAD_CTRL) > #define MX51_PAD_EIM_CS2__FEC_RDATA2 IOMUX_PAD(0x47c, 0x0e8, 3, > 0x960, > 0, NO_PAD_CTRL) > #define MX51_PAD_EIM_CS3__FEC_RDATA3 IOMUX_PAD(0x480, 0x0ec, 3, > 0x964, > 0, NO_PAD_CTRL) > > I'd expect all RDATA signals all having the same pad control settings. > They don't have, and I't doesn't make a difference, when I set them all > to PAD_CTRL_4 as the first one. The easiest way to get back to a working pin setup is probably to add a printk to the writel in iomux-v3.c in both the working and the nonworking barebox. It should be quite easy to figure out and bisect the differences then. Note that you once you have figured it out you should send the same patch for the kernel aswell. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/2] tx51: ensure eth phy resets properly by driving reset pin explicitly.
On Mon, Jul 16, 2012 at 11:53:58AM +0200, Christian Kapeller wrote: > > diff --git a/arch/arm/boards/karo-tx51/tx51.c > b/arch/arm/boards/karo-tx51/tx51.c > index 096683a..d862a68 100644 > --- a/arch/arm/boards/karo-tx51/tx51.c > +++ b/arch/arm/boards/karo-tx51/tx51.c > @@ -205,6 +205,12 @@ static inline void tx51_fec_init(void) > } > > /* > + *Turn off phy power, be cautious and wait > + */ > + gpio_set_value(TX51_FEC_PHY_PWR, 0); > + mdelay(20); Does this fix the mentioned regression due to iomuxing or is this another issue? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
On 07/16/2012 03:52 PM, christian.buett...@rafi.de wrote: > Thx for the hint. > What i don't understand is that barebox boots from nand but the > environement can't.. Good point. In any case the driver isn't able to recognize your nand device. I see from you supplied code snipplets, that your barebox is at least two weeks old. Maybe you use the upstream tree, as maybe there are already fixes for imx53 nand flash. Also you may want to activate mtd debugging: #define CONFIG_MTD_DEBUG #define CONFIG_MTD_DEBUG_VERBOSE 3 for example to your include/linux/mtd/mtd.h file. (Those are config settings, but they don't appear in any Kconfig file, hence supply them manually) good luck. > > >> I flashed from 0x0 to 0x7 (image size: 479K). >> I flashed the environment image (image size: 3K) from 0x8 to 0xF >> and changed the config code from barebox/environs/common/config to: >> >> ... >> nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)" >> ... >> >> Barebox can boot now but the startup log says: >> barebox 2012.03.0-dirty (Jul 16 2012 - 09:01:01) >> >> Board: i.MX53 >> eth@eth0: got MAC address from EEPROM: * >> nand_get_flash_type: second ID read did not match ef,ef against c0,c0 >> No NAND device found (-19)! >> Malloc space: 0x7df0 -> 0x7fef (size 32 MB) >> Stack space : 0x7def8000 -> 0x7df0 (size 32 kB) >> Open /dev/env0 No such file or directory >> running /env/bin/init... >> not found >> barebox:/ >> >> How can i get the environment loaded? > > Normally you would issue 'saveenv' which writes the environment to the > environment partition. On subsequent boots the environment will be loaded. > > But the flash device on your board isn't detected by barebox, so you > will have to fix the detection first. > >> nand_get_flash_type: second ID read did not match ef,ef against c0,c0 > > This line suggests, that the nand flash isn't working property. The line > is generated in drivers/mtd/nand/nand_base.c, after reading manufacturer > id and chip id two times, and checking them for equality. > > Not only does your board different values for manufacturer and flash id > on first and second read, but they are also the same. manuf id=ef and > chip id=ef isn't plausible. Maybe you should check your hardware. > > Regards > Christian > -- Christian Kapeller cmotion GmbH Kriehubergasse 16 1050 Wien / Austria http://www.cmotion.eu christian.kapel...@cmotion.eu Phone: +43 1 789 1096 38 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
ahh thank you.. i try that. Von:Christian Kapeller An: christian.buett...@rafi.de, Kopie: barebox@lists.infradead.org, Sascha Hauer Datum: 16.07.2012 16:26 Betreff:Re: Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size On 07/16/2012 03:52 PM, christian.buett...@rafi.de wrote: > Thx for the hint. > What i don't understand is that barebox boots from nand but the > environement can't.. Good point. In any case the driver isn't able to recognize your nand device. I see from you supplied code snipplets, that your barebox is at least two weeks old. Maybe you use the upstream tree, as maybe there are already fixes for imx53 nand flash. Also you may want to activate mtd debugging: #define CONFIG_MTD_DEBUG #define CONFIG_MTD_DEBUG_VERBOSE 3 for example to your include/linux/mtd/mtd.h file. (Those are config settings, but they don't appear in any Kconfig file, hence supply them manually) good luck. > > >> I flashed from 0x0 to 0x7 (image size: 479K). >> I flashed the environment image (image size: 3K) from 0x8 to 0xF >> and changed the config code from barebox/environs/common/config to: >> >> ... >> nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)" >> ... >> >> Barebox can boot now but the startup log says: >> barebox 2012.03.0-dirty (Jul 16 2012 - 09:01:01) >> >> Board: i.MX53 >> eth@eth0: got MAC address from EEPROM: * >> nand_get_flash_type: second ID read did not match ef,ef against c0,c0 >> No NAND device found (-19)! >> Malloc space: 0x7df0 -> 0x7fef (size 32 MB) >> Stack space : 0x7def8000 -> 0x7df0 (size 32 kB) >> Open /dev/env0 No such file or directory >> running /env/bin/init... >> not found >> barebox:/ >> >> How can i get the environment loaded? > > Normally you would issue 'saveenv' which writes the environment to the > environment partition. On subsequent boots the environment will be loaded. > > But the flash device on your board isn't detected by barebox, so you > will have to fix the detection first. > >> nand_get_flash_type: second ID read did not match ef,ef against c0,c0 > > This line suggests, that the nand flash isn't working property. The line > is generated in drivers/mtd/nand/nand_base.c, after reading manufacturer > id and chip id two times, and checking them for equality. > > Not only does your board different values for manufacturer and flash id > on first and second read, but they are also the same. manuf id=ef and > chip id=ef isn't plausible. Maybe you should check your hardware. > > Regards > Christian > -- Christian Kapeller cmotion GmbH Kriehubergasse 16 1050 Wien / Austria http://www.cmotion.eu christian.kapel...@cmotion.eu Phone: +43 1 789 1096 38 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 1/2] tx51: ensure eth phy resets properly by driving reset pin explicitly.
On 07/16/2012 04:25 PM, Sascha Hauer wrote: > On Mon, Jul 16, 2012 at 11:53:58AM +0200, Christian Kapeller wrote: >> >> diff --git a/arch/arm/boards/karo-tx51/tx51.c >> b/arch/arm/boards/karo-tx51/tx51.c >> index 096683a..d862a68 100644 >> --- a/arch/arm/boards/karo-tx51/tx51.c >> +++ b/arch/arm/boards/karo-tx51/tx51.c >> @@ -205,6 +205,12 @@ static inline void tx51_fec_init(void) >> } >> >> /* >> + *Turn off phy power, be cautious and wait >> + */ >> +gpio_set_value(TX51_FEC_PHY_PWR, 0); >> +mdelay(20); > > Does this fix the mentioned regression due to iomuxing or is this > another issue? Nope, that is another issue. This fix is from my v2012.03.0 branch. Without it the phy init worked only flaky. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/2] tx51: Disable kallsyms. It prevents the board from booting.
On Mon, Jul 16, 2012 at 11:53:59AM +0200, Christian Kapeller wrote: > > diff --git a/arch/arm/configs/tx51stk5_defconfig > b/arch/arm/configs/tx51stk5_defconfig > index 7fff0f0..e1796b9 100644 > --- a/arch/arm/configs/tx51stk5_defconfig > +++ b/arch/arm/configs/tx51stk5_defconfig > @@ -32,7 +32,6 @@ CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y > CONFIG_HAVE_CONFIGURABLE_MEMORY_LAYOUT=y > CONFIG_MEMORY_LAYOUT_DEFAULT=y > CONFIG_MALLOC_TLSF=y > -CONFIG_KALLSYMS=y Of course I rather would like to fix the underlying issue. Does this happen on a second stage barebox aswell? Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: barebox image size
Hi, Le Mon, 16 Jul 2012 16:25:57 +0200, Christian Kapeller a écrit : > On 07/16/2012 03:52 PM, christian.buett...@rafi.de wrote: > > Thx for the hint. > > What i don't understand is that barebox boots from nand but the > > environement can't.. > > Good point. In any case the driver isn't able to recognize your nand > device. I see from you supplied code snipplets, that your barebox is > at least two weeks old. Maybe you use the upstream tree, as maybe there > are already fixes for imx53 nand flash. > you may try the ONFI patches as the log "nand_get_flash_type: second ID read did not match ef,ef against c0,c0" seems very similar to what I already saw in the past on one of my i.MX53 based board : http://git.pengutronix.de/?p=barebox.git;a=commit;h=7baead578db7e47aedfcd3a5a21a69b9f37630d1 http://git.pengutronix.de/?p=barebox.git;a=commit;h=4b23222c4d68bf40ad89c99bf5e7fcbaa235bffb http://git.pengutronix.de/?p=barebox.git;a=commit;h=632c45795065e6a7471ab82be38e808eb6204341 Eric ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/2] tx51: Disable kallsyms. It prevents the board from booting.
On 07/16/2012 04:31 PM, Sascha Hauer wrote: > On Mon, Jul 16, 2012 at 11:53:59AM +0200, Christian Kapeller wrote: >> >> diff --git a/arch/arm/configs/tx51stk5_defconfig >> b/arch/arm/configs/tx51stk5_defconfig >> index 7fff0f0..e1796b9 100644 >> --- a/arch/arm/configs/tx51stk5_defconfig >> +++ b/arch/arm/configs/tx51stk5_defconfig >> @@ -32,7 +32,6 @@ CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y >> CONFIG_HAVE_CONFIGURABLE_MEMORY_LAYOUT=y >> CONFIG_MEMORY_LAYOUT_DEFAULT=y >> CONFIG_MALLOC_TLSF=y >> -CONFIG_KALLSYMS=y > > Of course I rather would like to fix the underlying issue. Does this > happen on a second stage barebox aswell? I hear you. My intend was to have at least a booting board, rather than a brick. I just flashed tx51 barebox without CONFIG_KALLSYMS, and could successfully start a barebox binary with CONFIG_KALLSYMS set using bootm. ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
RE: Atmel AT91 SD/MMC clock too fast
> -Original Message-
> From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
> Sent: Monday, July 16, 2012 1:33 AM
> To: George Pontis
> Cc: barebox@lists.infradead.org
> Subject: Re: Atmel AT91 SD/MMC clock too fast
>
> Hi George,
>
> On Mon, Jul 16, 2012 at 12:22:13AM -0700, George Pontis wrote:
> > Due to integer truncation, the calculated divisor for the SD/MMC clock
may
> > be too low, resulting in a clock that is too fast. For example, the
> > at91sam9g45 is typically run with a master clock at 133 MHz. There is no
> > divisor possible that will result in a 25 or 50 MHz clock as is
typically
> > used for a SD card. The existing code will set the clock at 33 MHz or 66
> MHz
> > when 25 or 50 MHz is requested. A Kingston class 10 8G SDHC was found to
> not
> > work properly at 33 MHz, but did after patching. The patch, in this
case,
> > generated a 22.1 MHz clock ( 133/6 ). This is the same frequency that
this
> > card sees after booting Linux. If a perfect integer division is
possible,
> > the patch will provide an exact clock rate. If not, the frequency will
be
> > the closest possible without exceeding the target.
> >
> > The following was based on barebox 2012-07:
> >
> > --- a/drivers/mci/atmel_mci.c 2012-07-02 01:31:52.0 -0700
> > +++ b/drivers/mci/atmel_mci.c 2012-07-15 23:14:02.203872596 -0700
> > @@ -76,7 +76,8 @@
> > unsigned int clk_in = clk_get_rate(host->clk);
> >
> > if (clk_ios > 0) {
> > - divider = (clk_in / clk_ios) / 2;
> > + /* don't allow integer truncation to result in too small
a
> > divider */
> > + divider = (clk_in + 2 * clk_ios - 1) / (2 * clk_ios);
>
> DIV_ROUND_UP(clk_in, clk_ios / 2) instead?
>
> Sascha
>
Looks good, but it needs a divisor of 2*clk_ios. Using that macro:
--- a/drivers/mci/atmel_mci.c 2012-07-02 01:31:52.0 -0700
+++ b/drivers/mci/atmel_mci.c 2012-07-15 23:14:02.203872596 -0700
@@ -76,7 +76,8 @@
unsigned int clk_in = clk_get_rate(host->clk);
if (clk_ios > 0) {
- divider = (clk_in / clk_ios) / 2;
+ /* don't allow integer truncation to result in too small a
divider */
+ divider = DIV_ROUND_UP( clk_in, (2 * clk_ios));
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/2] tx51: Disable kallsyms. It prevents the board from booting.
On Mon, Jul 16, 2012 at 04:41:45PM +0200, Christian Kapeller wrote: > On 07/16/2012 04:31 PM, Sascha Hauer wrote: > > On Mon, Jul 16, 2012 at 11:53:59AM +0200, Christian Kapeller wrote: > >> > >> diff --git a/arch/arm/configs/tx51stk5_defconfig > >> b/arch/arm/configs/tx51stk5_defconfig > >> index 7fff0f0..e1796b9 100644 > >> --- a/arch/arm/configs/tx51stk5_defconfig > >> +++ b/arch/arm/configs/tx51stk5_defconfig > >> @@ -32,7 +32,6 @@ CONFIG_HAVE_CONFIGURABLE_TEXT_BASE=y > >> CONFIG_HAVE_CONFIGURABLE_MEMORY_LAYOUT=y > >> CONFIG_MEMORY_LAYOUT_DEFAULT=y > >> CONFIG_MALLOC_TLSF=y > >> -CONFIG_KALLSYMS=y > > > > Of course I rather would like to fix the underlying issue. Does this > > happen on a second stage barebox aswell? > > I hear you. My intend was to have at least a booting board, rather than > a brick. > > I just flashed tx51 barebox without CONFIG_KALLSYMS, and could > successfully start a barebox binary with CONFIG_KALLSYMS set using > bootm. A binary built with CONFIG_KALLSYMS is >256k and without CONFIG_KALLSYMS it's smaller than 256k. Looking at the karo i.MX51 flash_header.c it seems it does it right: unsigned long __image_len_section barebox_len = DCD_BAREBOX_SIZE; Nevertheless 256k is a typical maximum bootloader size which is assumed in some places, I would start looking there. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v2] usb: gadget: enable for MXS
On Mon, Jul 16, 2012 at 10:15:31AM +0200, Marc Kleine-Budde wrote: > Signed-off-by: Marc Kleine-Budde > --- > Changes since v1: > - enable Arc OTG Driver, too (tnx Sascha) Applied, thanks Sascha > > Marc > > drivers/usb/gadget/Kconfig |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig > index f7f2697..465121c 100644 > --- a/drivers/usb/gadget/Kconfig > +++ b/drivers/usb/gadget/Kconfig > @@ -4,7 +4,7 @@ menuconfig USB_GADGET > > config USB_HAVE_GADGET_DRIVER > bool > - default y if ARCH_IMX || ARCH_AT91 || ARCH_PXA > + default y if ARCH_IMX || ARCH_MXS || ARCH_AT91 || ARCH_PXA > > if USB_GADGET > > @@ -17,7 +17,7 @@ choice > config USB_GADGET_DRIVER_ARC > bool > prompt "Arc OTG device core" > - depends on ARCH_IMX > + depends on ARCH_IMX || ARCH_MXS > select USB_GADGET_DUALSPEED > select POLLER > > -- > 1.7.10.4 > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH/Master] ARM/MXS: the GPIO bitkeeper enable logic is inverse to the pullup enable logic
On Wed, Jul 11, 2012 at 11:15:58AM +0200, Juergen Beisert wrote:
> While a set bit enables the pullup (if exists) it disables the bitkeeper (if
> exists). Both features are using the same register bit and only one of this
> feature is present on a per pin base.
>
> Signed-off-by: Juergen Beisert
Applied, thanks
Sascha
>
> diff --git a/arch/arm/mach-mxs/iomux-imx.c b/arch/arm/mach-mxs/iomux-imx.c
> index 9203588..784c506 100644
> --- a/arch/arm/mach-mxs/iomux-imx.c
> +++ b/arch/arm/mach-mxs/iomux-imx.c
> @@ -125,7 +125,7 @@ void imx_gpio_mode(uint32_t m)
> if (BK_PRESENT(m)) {
> reg_offset = calc_pullup_reg(gpio_pin);
> writel(0x1 << (gpio_pin % 32), IMX_IOMUXC_BASE + reg_offset +
> - (GET_BITKEEPER(m) == 1 ? BIT_SET : BIT_CLR));
> + (GET_BITKEEPER(m) == 1 ? BIT_CLR : BIT_SET));
> }
>
> if (GET_FUNC(m) == IS_GPIO) {
>
> --
> Pengutronix e.K. | Juergen Beisert |
> Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
>
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Antwort: Re: Antwort: Re: Antwort: Re: barebox image size
Hi, > I flashed from 0x0 to 0x7 (image size: 479K). > I flashed the environment image (image size: 3K) from 0x8 to 0xF Her you write 512k for env > and changed the config code from barebox/environs/common/config to: > > ... > nand_parts="512k(barebox)ro,768k(bareboxenv),4M(kernel),120M(root)" And here you say its 786k. Cheers, Marc ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
