Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables

2022-06-14 Thread Sascha Hauer 
On Sat, Jun 11, 2022 at 10:46:51PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
> 
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment vars binary data
> 2. Extracts variables as NVMEM cells
> 
> Current Linux's NVMEM sysfs API allows reading whole NVMEM data block.
> It can be used by user-space tools for reading U-Boot env vars block
> without the hassle of finding its location. Parsing will still need to
> be re-done there.
> 
> Kernel-parsed NVMEM cells can be read however by Linux drivers. This may
> be uesful for Ethernet drivers for reading device MAC address which is
> often stored as U-Boot env variable.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Use of_get_mtd_device_by_node() (thanks Ahmad) & update description
> V2: Drop ARCH_BCM4908 dependency as there are plenty architectures using
> U-Boot bootloader. Thanks Srinivas.
> 
> As noticed by Ahmad a missing NVMEM subsystem feature is user-space
> access to parsed NVMEM cells. That is something I started working on
> some time ago and I'm planning to get back to at some point, please
> check:
> [PATCH 2/2] nvmem: expose NVMEM cells in sysfs
> https://lore.kernel.org/lkml/20211220064730.28806-2-zaj...@gmail.com/
> ---
>  MAINTAINERS|   1 +
>  drivers/nvmem/Kconfig  |  11 ++
>  drivers/nvmem/Makefile |   2 +
>  drivers/nvmem/u-boot-env.c | 231 +
>  4 files changed, 245 insertions(+)
>  create mode 100644 drivers/nvmem/u-boot-env.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 475e28365385..43b427fa76b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20411,6 +20411,7 @@ U-BOOT ENVIRONMENT VARIABLES
>  M:   Rafał Miłecki 
>  S:   Maintained
>  F:   Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> +F:   drivers/nvmem/u-boot-env.c
>  
>  UACCE ACCELERATOR FRAMEWORK
>  M:   Zhangfei Gao 
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index d72d879a6d34..5f1b32b953b9 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -344,4 +344,15 @@ config NVMEM_APPLE_EFUSES
> This driver can also be built as a module. If so, the module will
> be called nvmem-apple-efuses.
>  
> +config NVMEM_U_BOOT_ENV
> + tristate "U-Boot environment variables support"
> + depends on OF && MTD
> + select CRC32
> + help
> +   U-Boot stores its setup as environment variables. This driver adds
> +   support for verifying & exporting such data. It also exposes variables
> +   as NVMEM cells so they can be referenced by other drivers.
> +
> +   If compiled as module it will be called nvmem_u-boot-env.
> +
>  endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index c710b64f9fe4..399f9972d45b 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -69,3 +69,5 @@ obj-$(CONFIG_NVMEM_APPLE_EFUSES)+= nvmem-apple-efuses.o
>  nvmem-apple-efuses-y := apple-efuses.o
>  obj-$(CONFIG_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
>  nvmem-microchip-otpc-y   := microchip-otpc.o
> +obj-$(CONFIG_NVMEM_U_BOOT_ENV)   += nvmem_u-boot-env.o
> +nvmem_u-boot-env-y   := u-boot-env.o
> diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
> new file mode 100644
> index ..92c2dd11d99f
> --- /dev/null
> +++ b/drivers/nvmem/u-boot-env.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Rafał Miłecki 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum u_boot_env_format {
> + U_BOOT_FORMAT_SINGLE,
> + U_BOOT_FORMAT_REDUNDANT,
> +};
> +
> +struct u_boot_env {
> + struct device *dev;
> + enum u_boot_env_format format;
> +
> + /* Parent device */
> + struct mtd_info *mtd;
> + size_t offset;
> + size_t size;
> +
> + /* Cells */
> + struct nvmem_cell_info *cells;
> + int ncells;
> +};
> +
> +struct u_boot_env_image_single {
> + __le32 crc32;
> + uint8_t data[0];
> +} __packed;
> +
> +struct u_boot_env_image_redundant {
> + __le32 crc32;
> + u8 mark;
> + uint8_t data[0];
> +} __packed;
> +
> +static int u_boot_env_read(void *context, unsigned int offset, void *val,
> +size_t bytes)
> +{
> + struct u_boot_env *priv = context;
> + struct device *dev = priv->dev;
> + size_t bytes_read;
> + int err;
> +
> + err = mtd_read(priv->mtd, priv->offset + offset, bytes, &bytes_read, 
> val);
> + if (err && !mtd_is_bitflip(err)) {
> + dev_err(dev, "Failed to read from mtd: %d\n", err);
> + return err;
> + }
> +
> + if (bytes_read != bytes) {
> + dev_err(dev, "Failed to read %zd bytes\n", bytes);
> + r

Re: [PATCH] arm64: dts: ls1046ardb: Set aqr106 phy mode to usxgmii

2020-04-28 Thread Sascha Hauer 
Hi Madalin,

On Thu, Apr 23, 2020 at 12:59:16PM +, Madalin Bucur wrote:
> > -Original Message-
> > From: Sascha Hauer 
> > Sent: Thursday, April 23, 2020 1:22 PM
> > To: linux-arm-ker...@lists.infradead.org
> > Cc: Madalin Bucur ; Shawn Guo
> > ; Leo Li ; Sascha Hauer
> > 
> > Subject: [PATCH] arm64: dts: ls1046ardb: Set aqr106 phy mode to usxgmii
> > 
> > The AQR107 family of phy devices do not support xgmii, but usxgmii
> > instead. Since ce64c1f77a9d ("net: phy: aquantia: add USXGMII support
> > and warn if XGMII mode is set") the kernel warns about xgmii being
> > used. Change device tree to usxgmii.
> > 
> > Signed-off-by: Sascha Hauer 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > index d53ccc56bb63..02fbef92b96a 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
> > @@ -151,7 +151,7 @@ ethernet@ea000 {
> > 
> > ethernet@f { /* 10GEC1 */
> > phy-handle = <&aqr106_phy>;
> > -   phy-connection-type = "xgmii";
> > +   phy-connection-type = "usxgmii";
> > };
> > 
> > ethernet@f2000 { /* 10GEC2 */
> > --
> > 2.26.1
> 
> Hi Sascha,
> 
> thank you for trying to correct this problem. Unfortunately
> "usxgmii" here is incorrect too, as that mode is not supported
> by the LS1046A SoC. The connection mode used, as documented
> by the SoC and PHY datasheets, is XFI. Unfortunately there was
> resistance against including this connection type in the list
> supported by the kernel (please note the distinction between
> connection type and connection mode). At a certain moment the
> two were aliased and the kernel uses connection mode, not
> connection type. While we should describe here the hardware,
> the board connection type (XFI), in the kernel the connection
> mode was lately preferred (10G-BaseR). So, today we cannot use
> "xfi" here, as the hardware description property should read.
> The closest thing we can use is "10gbase-r". Unfortunately, in
> u-boot support for "xfi" is already in place [1] and the device
> tree should be different for the two for this reason - this goes
> against the spirit of the device tree that should not depend on
> the software using it...
> 
> I had on my agenda to fix this problem, had to stop when "xfi"
> was rejected, at the time not even "10gbase-r" was an option.
> Also worth noting here is that, while we change "xgmii" to a
> correct/better value, we should also tolerate the old variant,
> as there are users in the wild unable/unwilling to update the
> device tree and backwards compatibility should be ensured,
> further complicating the matter.

Thanks for the explanation. It looked like one of those simple patch
opportunities at first, apparently it isn't.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [U-Boot] [PATCH 1/2] i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU before bootm

2012-09-23 Thread Sascha Hauer 
On Sun, Sep 23, 2012 at 07:27:41PM +0200, Stefano Babic wrote:
> 
> > 
> > I would like to see a handoff of display settings from U-Boot to
> > the kernel, but that's also a tricky thing as long as we're supporting
> > different mechanisms (DT in main-line and kernel parameters in
> > older kernels).
> 
> Yes, and a lot of other things. I know Anatolji implemented this
> behavior for a PPC5121, but we cannot generalize. I agree that the
> handoff is difficult and not maintainable. My question is different: if
> the IPU drivers in kernel are compiled as modules, and I will load them
> only after booting, and the framebuffer's memory is reserved so that the
> kernel does not touch it, is there still a known reason because the IPU
> should not run when we boot the kernel? I know this issue with USB,
> maybe we have now the same with the IPU.

The clock framework disables all unused clocks in a late_initcall. when
the IPU is compiled as a module, the IPU clock will be one of those.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [ANNOUNCEMENT] U-Boot-v2 has its own list

2009-10-29 Thread Sascha Hauer 

Hi all,

U-Boot-v2 now has its own list on infradead.org. If you are interested
in U-Boot-v2 development please subscribe here:

http://lists.infradead.org/mailman/listinfo/u-boot-v2

So as of now all v2 related topics should go over this list.

Thanks

  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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH U-BOOTV2] image.h: amd64 support

2009-10-21 Thread Sascha Hauer 
Hi Peter,

On Tue, Oct 20, 2009 at 10:21:00PM +0200, Peter Korsgaard wrote:
> Use IH_CPU_I386 for amd64 machines as well, so bootm.c is able to build
> on amd64 sandbox.
> 
> Signed-off-by: Peter Korsgaard 


Applied, thanks.

Sascha

> ---
>  include/image.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/image.h b/include/image.h
> index 0d2f472..5524f84 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -84,7 +84,7 @@
>  #define IH_CPU IH_CPU_PPC
>  #elif defined(__ARM__)
>  #define IH_CPU IH_CPU_ARM
> -#elif defined(__I386__)
> +#elif defined(__I386__) || defined(__x86_64__)
>  #define IH_CPU IH_CPU_I386
>  #elif defined(__mips__)
>  #define IH_CPU IH_CPU_MIPS
> -- 
> 1.6.3.3
> 
> 

-- 
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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] Add Eukrea CPUIMX27 support

2009-07-16 Thread Sascha Hauer 
Hi Eric,

On Wed, Jul 15, 2009 at 05:18:39PM +0200, Eric Benard wrote:
> CPUIMX27 is built around Freescale's i.MX27 and has up to 64MB of
> NOR Flash, up to 512MB of NAND Flash and up to 256MB of mDDR,
> it includes an ethernet PHY in MII mode, an I2C RTC and a
> ST16554 QuadUART on nCS3.

Looks good. Applied, thanks.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] remove myself as phycore/litekit Maintainer

2009-05-15 Thread Sascha Hauer 



I never acked a patch that adds me as phycore i.MX31 maintainer nor was
it me who pushed the patches, so remove myself from the maintainer list
so that other people do not longer wait for my ack.

Signed-off-by: Sascha Hauer 
---
 MAINTAINERS |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6bb03b4..be10d50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -539,11 +539,6 @@ Kshitij Gupta 
omap1510inn ARM925T
omap1610inn ARM926EJS
 
-Sascha Hauer 
-
-   imx31_litekit   i.MX31
-   imx31_phycore   i.MX31
-
 Grazvydas Ignotas 
 
omap3_pandora   ARM CORTEX-A8 (OMAP3xx SoC)
-- 
1.6.2.1

-- 
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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] mx27: basic cpu support

2009-05-14 Thread Sascha Hauer 
On Thu, May 14, 2009 at 10:10:07AM +0200, Wolfgang Denk wrote:
> Dear Ilya Yanok,
> 
> In message <4a0b4f9a.8030...@emcraft.com> you wrote:
> > 
> > >> +return 2600 / 1.5;
> > >
> > > We definitely do not allow any FP use in U-Boot.
> > 
> > This will be actually converted to an integer at the compile time.
> 
> Maybe. But it's also trivial not to use any FP calculations at all.
> 
> > >> +void imx_gpio_mode(int gpio_mode)
> > >> +{
> > >> +unsigned int pin = gpio_mode & GPIO_PIN_MASK;
> > >> +unsigned int port = (gpio_mode & GPIO_PORT_MASK) >> 
> > >> GPIO_PORT_SHIFT;
> > >> +unsigned int ocr = (gpio_mode & GPIO_OCR_MASK) >> 
> > >> GPIO_OCR_SHIFT;
> > >> +unsigned int aout = (gpio_mode & GPIO_AOUT_MASK) >> 
> > >> GPIO_AOUT_SHIFT;
> > >> +unsigned int bout = (gpio_mode & GPIO_BOUT_MASK) >> 
> > >> GPIO_BOUT_SHIFT;
> > >> +unsigned int tmp;
> > >> +
> > >> +/* Pullup enable */
> > >> +if(gpio_mode & GPIO_PUEN)
> > >> +PUEN(port) |= (1 << pin);
> > >> +else
> > >> +PUEN(port) &= ~(1 << pin);
> > >> 
> > >
> > > This smells as if these were pointer accesses using register offsets
> > > instead of I/O accessor calls using C structs?
> > >   
> > 
> > Ok, I really like using accessor calls instead of pointer accesses but I
> > don't really understand the reason for using C structs here... I
> > remember I've already asked you about that and you told me that it's for
> > type safety... But we loose this type-safety when we are using I/O
> > accessor functions! All pointers are just silently converted to the
> > needed type... 
> 
> They are not _silently_ converted. They raise compiler warnings. If,
> for example, I try to access a 32 bit register using a 16 bit I/O
> accessor function as simulated by this (bogus) change:
> 
> -   out_be32(&fec->eth->r_des_active, 0x0100);
> +   out_be16(&fec->eth->r_des_active, 0x0100);
> 
> then the compiler will complain:
> 
> mpc512x_fec.c: In function 'mpc512x_fec_rbd_clean':
> mpc512x_fec.c:125: warning: passing argument 1 of 'out_be16' from 
> incompatible pointer type
> 
> I never understood why you claim such type checking would not
> happen...
> 
> >... On the other hand Linux uses offsets for registers
> > definitions so converting them to C structs makes porting and
> > maintaining ported drivers harder...
> 
> It is incorrect to state that "Linux uses offsets for registers". The
> Linux code for ARM may do this, and I consider this one of the major
> deficiencies of the ARM code in Linux. Other architectures (like
> PowerPC) deprecated this long ago.

Can you provide some pointers to a discussion? I sometimes google for
this topic, but I never found something relevant.

> 
> And in U-Boot we also don't accept this any more.
> 
> > > You probably want to use the respective clrbits*() / setbits*() macros
> > > here?
> > 
> > I can see these macros defined only for ppc arch... And I really prefer
> > generic writel(readl() | something) here... The reason is the same: to
> > preserve as much code as it possible in drivers ported from Linux.
> 
> Yes, I am aware of this. This is another area where cleanup is needed.

The good thing about writel(readl() | something) is that this makes it
clear that this operation is not atomic.

> 
> Note that I'm not sure if readl() can be considered "generic" across
> architectures. If my understanding is correct, then in Linux the
> ioread() / iowrite() are considered portable and should be used, i. e.
> ioread16(), ioread16be(), ioread32(), ioread32be() etc., with the
> plain ioread*() [i. e. without the "be" part] being little-endian on
> all architectures.
> 
> > >> +#define IMX_AIPI1_BASE (0x0 + IMX_IO_BASE)
> > >> +#define IMX_WDT_BASE   (0x02000 + IMX_IO_BASE)
> > >> +#define IMX_TIM1_BASE  (0x03000 + IMX_IO_BASE)
> > >> +#define IMX_TIM2_BASE  (0x04000 + IMX_IO_BASE)
> > >> +#define IMX_TIM3_BASE  (0x05000 + IMX_IO_BASE)
> > >> +#define IMX_UART1_BASE (0x0a000 + IMX_IO_BASE)
> > >> +#define IMX_UART2_BASE (0x0b000 + IMX_IO_BASE)
> > >> +#define IMX_UART3_BASE (0x0c000 + IMX_IO_BASE)
> > >> +#define IMX_UART4_BASE (0x0d000 + IMX_IO_BASE)
> > >> +#define IMX_I2C1_BASE  (0x12000 + IMX_IO_BASE)
> > >> +#define IMX_GPIO_BASE  (0x15000 + IMX_IO_BASE)
> > >> +#define IMX_TIM4_BASE  (0x19000 + IMX_IO_BASE)
> > >> +#define IMX_TIM5_BASE  (0x1a000 + IMX_IO_BASE)
> > >> +#define IMX_UART5_BASE (0x1b000 + IMX_IO_BASE)
> > >> +#define IMX_UART6_BASE (0x1c000 + IMX_IO_BASE)
> > >> +#define IMX_I2C2_BASE  (0x1D000 + IMX_IO_BASE)
> > >> +#define IMX_TIM6_BASE  (0x1f000 + IMX_IO_BASE)
> > >> +#define IMX_AIPI2_BASE (0x2 + IMX_IO_BASE)
> > >> +#define IMX_PLL_BASE

Re: [U-Boot] [u-boot v2] and i2c

2009-04-28 Thread Sascha Hauer 
Hi Heiko,

On Tue, Apr 28, 2009 at 09:36:46AM +0200, Heiko Schocher wrote:
> Hello Sascha,
> 
> I actually looked in the u-boot-v2.git in the i2c branch,
> because I wanted to look how things in v2 work, specially
> I2C Subsystem ... and I have a first question:

Note that the I2C branch is out of date and probably needs some
updating. That does not affect your current problem though.

> 
> - In ppc area, we start running from flash and have to relocate
>   code. Before setting up RAM, we maybe have to read SPD EEprom
>   over I2C for this. How could this work in v2? I see in
>   drivers/i2c/i2c-core.c in i2c_register_adapter () an
>   INIT_LIST_HEAD(&adap->clients);
> 
>   This could not work, when running from Flash, because we have no
>   usable RAM ...
>   So I looked how this device approach globally works, and found in
>   lib/driver.c in register_device() also:
> 
>   107
>   108 list_add_tail(&new_device->list, &device_list);
>   109 INIT_LIST_HEAD(&new_device->children);
>   110
> 
>   so would this device_driver approach in v2 actually only work,
>   if running from RAM?

Yes

> What if we need the devices earlier?

You would need portions of the driver which bypass the I2C framework.
I did something similar for the console (see
drivers/serial/serial_mpc5xxx.c). This is not particularly nice but I
see no other way handling this. If done with care you can reuse most
of the driver code.
Once the framework is initialized the normal functions can be used.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Build errors u-boot-v2 iMX27

2009-04-22 Thread Sascha Hauer 
On Mon, Apr 20, 2009 at 02:18:21PM -0400, Bill Cook wrote:
> > -Original Message-
> > From: saschaha...@web.de [mailto:saschaha...@web.de]on Behalf Of Sascha
> > Hauer
> > Sent: Monday, April 20, 2009 12:57 PM
> > To: Bill Cook
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] Build errors u-boot-v2 iMX27
> > 
> > 
> > Hi Bill,
> > 
> > On Mon, Apr 20, 2009 at 10:57:49AM -0400, Bill Cook wrote:
> > > Dear ML,
> > > 
> > > I'm trying to build u-boot-v2 for an iMX27 based board. I'm getting a
> > > HW/SW floating point mismatch error and hope someone will point me
> > > to a solution.  Building with:
> 
> > > Error is:
> > > 
> > > arm-eabi-ld: ERROR: arch/arm/lib/_ashldi3.o uses hardware FP, whereas
> > > arch/arm/lib/built-in.o uses software FP
> > > arm-eabi-ld: failed to merge target specific data of file
> > > arch/arm/lib/_ashldi3.o
> > > 
> > > 
> > > The source files are assembly, any C files have the -msoft-float 
> > compile option.
> > > What gives?
> > 
> > All our toolchains produce soft float by default, so this does not show
> > up here. U-Boot does not use floating point, so I think we do not have
> > to care what the compiler produces. Does it help to remove the
> > -msoft-float from arch/arm/Makefile?
> > 
> 
> Yes, this did the trick, I knew it had to be something simple...
> Thanks.

Ok, I removed -msoft-float.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANNOUNCE] Kconfig support

2009-04-21 Thread Sascha Hauer 
On Tue, Apr 21, 2009 at 10:08:38PM +0200, Wolfgang Denk wrote:
> Dear Sascha,
> 
> In message <20090421182102.gz21...@pengutronix.de> you wrote:
> >
> > > This is not quite correct. What  I  consider  important  is  an  evo-
> > > lutionary path - this may include bigger changes and reorganizations,
> > > but  I  consider  it a bad idea to not provide a reasonable migration
> > > path for larger parts of the existing community.
> > 
> > Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
> > two incompatible network driver APIs for at least the last seven years and
> > still 19 drivers have not switched to the new API.
> 
> What exactly do you complain about? Have there been any such patches
> posted that I 9or anybody else) rejected?
> 
> > It was exactly this kind of stagnation that made me fork U-Boot. I was
> 
> You did not even attempt to fix this, or did you, and I repressed the
> memory of this?

No, neither I tried to fix it nor did anybody else. Probably because
noone wants to dig through numerous drivers for which he most likely does
not even have the hardware. The solution is to mark them as broken and
you'll get the relevant patches within a week. The drivers which are
still not fixed after some months can be removed as nobody seems to have
interest in them. I know this is a strong weapon which should be handled
with care, but I think sometimes it's necessary to use it.

s...@octopus:~/octopus/u-boot/u-boot find board -name "flash.c" | wc -l
201
s...@octopus:~/octopus/u-boot/u-boot find board -name "config.mk"| wc -l
411

So nearly half of the boards in U-Boot seem to be unmaintained since the
advent of the generic flash driver five years ago.
How can you possibly ever change the API for the flash driver with 201
different flash drivers in the tree without marking something as broken?
One of these boards is the Auerswald Innokom, a board Robert once
ported. We probably still have it somewhere @Pengutronix, but nobody in
the world has any interest in running a top of tree U-Boot on it. Still
it is in the tree and by policy it has to be supported for all eternity.
Mark the boards as broken, remove them and give the others some air to
breeze to actually change something without drowning in legacy code.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANNOUNCE] Kconfig support

2009-04-21 Thread Sascha Hauer 
On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote:
> Dear Robert,
> 
> just to put a few points right:
> 
> In message <20090421070431.gx5...@pengutronix.de> you wrote:
> >
> > So our intention was and is:
> > 
> > 1. Wolfgang has a focus on stability and gradual changes. We respect this
> >political position because it is a *good* one.
> 
> This is not quite correct. What  I  consider  important  is  an  evo-
> lutionary path - this may include bigger changes and reorganizations,
> but  I  consider  it a bad idea to not provide a reasonable migration
> path for larger parts of the existing community.

Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries
two incompatible network driver APIs for at least the last seven years and
still 19 drivers have not switched to the new API.

It was exactly this kind of stagnation that made me fork U-Boot. I was
really tired of this ongoing "no, please don't break existing code". And
honestly, I was so blinded by ifdefs that I couldn't even see what the
existing code was. So I started hacking on U-Boot in my spare time, not
knowing where this would lead, but I must admit that it was really fun
to remove everything which I didn't know for what it was good for. You'd
be surprised to see how much dead code hides in U-Boot. Additionally
I wanted to see what's possible. Is it possible to integrate a driver
model without adding much binary space? Is it possible to create a
filesystem layer in this limited space? You see I was in a hacking mood
and not in a discuss-on-mailing-lists mood. What would have happened if
I posted a "I want a driver model" mail on the list? Probably one of the
first answers would have been "U-Boot is about size and simplicity".
Some mails later I probably would have gone back to business as usual.
Even if I tried to integrate a driver model into current U-Boot, how
long would it take till all drivers make use of it given the fact that
a simple thing like CONFIG_NET_MULTI stays for seven years?

I started this for fun, but I think integrating a driver model into
U-Boot without breaking existing stuff is no fun at all and I'm pretty
sure none of our customers would have payed us for working on this
topic.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address

2009-04-21 Thread Sascha Hauer 
On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote:
> If the MAX address is given by the environment, write it back to the
> hardware.
> 
> Signed-off-by: Daniel Mack 
> Cc: Sascha Hauer 

Acked-by: Sascha Hauer 

Anyway, you shouldn't rely on this. I'm the original author of this
driver, but I do not use U-Boot-v1 anymore, so I can't tell if this
breaks something or not.

Sascha

> ---
>  drivers/net/smc911x.c |9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 30f2dc2..8c9a2a8 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
>   unsigned long addrh, addrl;
>   uchar m[6];
>  
> - /* if the environment has a valid mac address then use it */
> - if (!eth_getenv_enetaddr("ethaddr", m)) {
> + if (eth_getenv_enetaddr("ethaddr", m)) {
> + /* if the environment has a valid mac address then use it */
> + addrl = m[0] | (m[1] << 8) | (m[2] << 16) | (m[3] << 24);
> + addrh = m[4] | (m[5] << 8);
> + smc911x_set_mac_csr(ADDRL, addrl);
> + smc911x_set_mac_csr(ADDRH, addrh);
> + } else {
>   /* if not, try to get one from the eeprom */
>   addrh = smc911x_get_mac_csr(ADDRH);
>   addrl = smc911x_get_mac_csr(ADDRL);
> -- 
> 1.6.2.1
> 
> 

-- 
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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Build errors u-boot-v2 iMX27

2009-04-20 Thread Sascha Hauer 
Hi Bill,

On Mon, Apr 20, 2009 at 10:57:49AM -0400, Bill Cook wrote:
> Dear ML,
> 
> I'm trying to build u-boot-v2 for an iMX27 based board. I'm getting a
> HW/SW floating point mismatch error and hope someone will point me
> to a solution.  Building with:
>   make ARCH=arm CROSS_COMPILE=arm-eabi-
> It works along fine until I get an error on each of these files:
>   arch/arm/lib/_ashldi3.o
>   arch/arm/lib/_ashrdi3.o
>   arch/arm/lib/_divsi3.o
>   arch/arm/lib/_modsi3.o
>   arch/arm/lib/_udivsi3.o
>   arch/arm/lib/_umodsi3.o
>   arch/arm/lib/_lshrdi3.o
>   arch/arm/lib/findbit.o
>   arch/arm/lib/io-readsb.o
>   arch/arm/lib/io-readsw-armv4.o
>   arch/arm/lib/io-writesb.o
>   arch/arm/lib/io-writesw-armv4.o
> 
> Error is:
> 
> arm-eabi-ld: ERROR: arch/arm/lib/_ashldi3.o uses hardware FP, whereas
> arch/arm/lib/built-in.o uses software FP
> arm-eabi-ld: failed to merge target specific data of file
> arch/arm/lib/_ashldi3.o
> 
> 
> The source files are assembly, any C files have the -msoft-float compile 
> option.
> What gives?

All our toolchains produce soft float by default, so this does not show
up here. U-Boot does not use floating point, so I think we do not have
to care what the compiler produces. Does it help to remove the
-msoft-float from arch/arm/Makefile?

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANNOUNCE] Kconfig support

2009-04-20 Thread Sascha Hauer 
On Mon, Apr 20, 2009 at 11:20:50AM -0400, Mike Frysinger wrote:
> On Monday 20 April 2009 10:53:39 Robert Schwebel wrote:
> > On Mon, Apr 20, 2009 at 10:42:08AM -0400, Mike Frysinger wrote:
> > > > U-Boot-v2 is used here to do real work in our projects. If it isn't
> > > > what you need, it is perfectly fine if you ignore it.
> > >
> > > my concern isnt really narrow to the Blackfin port. i was using it as
> > > a practical example. we've talked about v2 in the past as the answer
> > > to many of our problems and so we dont bother doing it in v1. but that
> > > approach looks to be wrong as v2 is of little practical importance.
> > > instead we should be doing what Jean-Christophe is doing: poaching
> > > good ideas until we get to the point where v2 can simply die.
> >
> > If you mean "you" while saying "we", then yes, it may be correct that
> > this is your plan. "We" don't have any plans to let v2 die.
> >
> > Should we be mindful of the future? But not at the expense of the
> > moment. Be mindful of the living Force, my young Padawan.
> 
> i never said "kill it now"; quite the opposite really.  in fact, it looks 
> like 
> you really arent taking your own saying to heart.  my point is to look to the 
> future and stop wasting resources.  if v1 incorporates all the features of 
> v2, 
> then v2 has no purpose at all except to split development and waste peoples 
> time.

Well as you said at the moment there is not much community around
u-boot-v2, so it's basically *our* time which we waste, and we are free
to do so. At the moment it seems you're wasting *your* time by warming
up this stupid discussion which Jerry already led to a nice ending.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ANNOUNCE] Kconfig support

2009-04-19 Thread Sascha Hauer 
On Sun, Apr 19, 2009 at 04:59:41PM -0500, Kumar Gala wrote:
>
> On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote:
>
>> On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote:
>>> u-boot-v2 is an interesting approach in several aspects, but since it
>>> was made publicly visible nearly two years ago it did not collect  
>>> much
>>> of a community around it.
>>
>> Right; part of the reason is it was always something we used to solve
>> our problems, and we didn't do much marketing around it. Nevertheless,
>> it *does* solve our problems very well, and each time we have to work
>> with v1 again it's weaknesses show up again and again.
>
> What's the summary of features that v2 has that v1 doesnt?

- Kconfig support
- Linux Build support
- Clean device registration and driver matching, so there can always be
  multiple instances of a device
- filesystem support. U-Boot starts by mounting a ramfs on /, populating
  a devfs under /dev and load the environemt to /env. Use the normal
  commands like cd, ls, rm, cat,...
- mount: there is no mmc_ls and mmc_load and stuff like that. Just mount
  your device and use ls
- The environment is not limited to a variable store, instead it's a
  ramfs which can store variables, scripts, splashimages or whatever
- module support
- One image for all storage types. Well, the hardware has to support it,
  but on i.MX27 the same image can start from RAM, Nor Flash and NAND
  Flash.
- USB Network support
- A network phy device layer, so phys are handled in a generic way.
  Their registers can be showed with md -s /dev/phy0 (and of course
  changed with mw)
- A much simpler clock implementation (Linux clocksource). So basically
  what an architecture needs to do is to specify the timer resolution
  and provide a read_timer function which returns the raw timer value.
- getopt support, so there is no need for positional arguments
- A simple editor to edit scripts
- readline usable on the command line to allow for interactive scripts
- a sandbox port to run U-Boot on the host including tap ethernet
- different bugs to hunt for

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Make flash protection work, when the environment is in EEPROM

2009-03-23 Thread Sascha Hauer 
On Sun, Mar 22, 2009 at 11:01:09PM -0400, Jon Smirl wrote:
> On Sun, Mar 22, 2009 at 6:59 PM, Sascha Hauer  wrote:
> > Hi Wolgang,
> >
> > On Sat, Mar 21, 2009 at 09:24:05PM +0100, Wolfgang Denk wrote:
> >> Dear Jon Smirl,
> >>
> >> In message <9e4733910903211308v63878fabx19f3327371db5...@mail.gmail.com> 
> >> you wrote:
> >> >
> >> > My guess is getenv() returns a pointer to the environment variable,
> >> > not a copy of the environment variable. getenv_r() returns a copy. How
> >> > can you return a pointer to the variable if the variable is in
> >> > something not directly addressable like EEPROM?  Does
> >>
> >> The environment always gets copied to RAM. And it's a perfectly simple
> >> thing to return an adress pointing to some memory in RAM :-)
> >>
> >> > getenv("unlock"); do what you want when the environment is in EEPROM?
> >>
> >> getenv() always works that way, no matter which actual media is used
> >> for the persistent storage of the environment.
> >
> > This is not quite true. In the PPC init sequence flash_init() is called
> > before env_relocate() and thus getenv is not available in flash_init().
> > Please note that this was just a quick way for us to make things work
> > and I never considered this a fix for mainline.
> 
> What is your fix for mainline?

I have none.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] mpc5200: make i2c faster

2009-03-22 Thread Sascha Hauer 
Hi,

On Sat, Mar 21, 2009 at 09:38:48AM -0400, Jon wrote:
> From: Sascha Hauer 
> 
> The mpc5xxx i2c driver has great delays while waiting for the chip status.
> make the delays smaller and the driver faster.
> 
> Signed-off-by: Sascha Hauer 
> ---
>  cpu/mpc5xxx/i2c.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/cpu/mpc5xxx/i2c.c b/cpu/mpc5xxx/i2c.c
> index 843af9c..41feb1d 100644
> --- a/cpu/mpc5xxx/i2c.c
> +++ b/cpu/mpc5xxx/i2c.c
> @@ -38,7 +38,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  #error CONFIG_SYS_I2C_MODULE is not properly configured
>  #endif
>  
> -#define I2C_TIMEOUT  100
> +#define I2C_TIMEOUT  1
>  #define I2C_RETRIES  3
>  
>  struct mpc5xxx_i2c_tap {
> @@ -94,7 +94,7 @@ static int wait_for_bb(void)
>   mpc_reg_out(®s->mcr, 0, 0);
>   mpc_reg_out(®s->mcr, I2C_EN, 0);
>  #endif
> - udelay(1000);
> + udelay(1);
>   status = mpc_reg_in(®s->msr);
>   }
>  

The actual condition we wait for takes only a few useconds to become
true, but we wait for at least 1ms. As the I2C EEPROM environment
routine reads nearly the complete EEPROM several times during startup
the speed gain is enormous.
I can't recall if it was intentional to reduce the overall timeout with
this patch, but I can imagine that the i2c detect function will be
faster aswell.

> @@ -109,7 +109,7 @@ static int wait_for_pin(int *status)
>   *status = mpc_reg_in(®s->msr);
>  
>   while (timeout-- && !(*status & I2C_IF)) {
> - udelay(1000);
> + udelay(1);
>   *status = mpc_reg_in(®s->msr);

Same 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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Make flash protection work, when the environment is in EEPROM

2009-03-22 Thread Sascha Hauer 
Hi Wolgang,

On Sat, Mar 21, 2009 at 09:24:05PM +0100, Wolfgang Denk wrote:
> Dear Jon Smirl,
> 
> In message <9e4733910903211308v63878fabx19f3327371db5...@mail.gmail.com> you 
> wrote:
> >
> > My guess is getenv() returns a pointer to the environment variable,
> > not a copy of the environment variable. getenv_r() returns a copy. How
> > can you return a pointer to the variable if the variable is in
> > something not directly addressable like EEPROM?  Does
> 
> The environment always gets copied to RAM. And it's a perfectly simple
> thing to return an adress pointing to some memory in RAM :-)
> 
> > getenv("unlock"); do what you want when the environment is in EEPROM?
> 
> getenv() always works that way, no matter which actual media is used
> for the persistent storage of the environment.

This is not quite true. In the PPC init sequence flash_init() is called
before env_relocate() and thus getenv is not available in flash_init().
Please note that this was just a quick way for us to make things work
and I never considered this a fix for mainline.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i.MX31: fir imx31_phycore to work after Linux reboot

2009-02-23 Thread Sascha Hauer 
Hi,

On Sat, Feb 21, 2009 at 10:32:33PM +0100, Wolfgang Denk wrote:
> Dear Guennadi Liakhovetski,
> 
> In message  you wrote:
> > 
> > > In message  you wrote:
> > > > Upon power on i.MX31 enables most peripheral clocks, Linux disables the 
> > > > ones
> > > 
> > > Why does U-Boot do that?
> > 
> > i.MX31 does that - the CPU, not U-Boot. I.e., this is the default power-on 
> > mode.
> 
> Yea, but U-Boot performs h/w initialization. So why does it not - like
> Linux - set sane defaults (with only the necessary clocks enabled) ?

I simply forgot it. The clock registers do not get resetted on reset,
only on power up.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] IMX27 nand_probe problem

2009-02-08 Thread Sascha Hauer 
Hi,

When writing about U-Boot-V2 please Cc me as I do not read this list as
regularly as I should.

On Tue, Jan 13, 2009 at 10:16:24PM +0100, Alessandro Chies wrote:
> Good morning,
>   I'm try to port uboot on a my board imx27 based. It has only DDR RAM 
> and a
> NAND flash.
> UBoot runs very well (if i don't activate the NAND) compiling it and
> uploading the bin directly to the processor via serial boot.
> If I activate the NAND support and try to intialize driver and device
> "nand0", I have a hang-up of the microprocessor in the probe function when
> it trys "tmp=readw(0xd8000e1a)".
> If I read with a "md 0xe8000e1a+0x02" from the uboot command line I don't
> have hangs (of course without the nand device registration).
> What could it be hanging me on this?

Have you checked the address? Is host->regs really set to the correct
value? Also, md does a 32bit access by default. To do 16bit accesses use
md -w. The area might not be accessible when the corresponding clock is
not turned on, but this should be done some lines above with
PCCR1 |= PCCR1_NFC_BAUDEN. The clock may be dependent on some other
clock, you could insert a PCCR0 = 0x; PCCR1 = 0x to turn
on all possible clocks to see if this is the reason.

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- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot-v2][PATCH] imx27: nandboot with 2k pages

2008-12-12 Thread Sascha Hauer 
Hi Frederic,

The patches look good in general, but unfortunately you mailer turned
tabs into spaces and wrapped long lines, so the patches do not apply.
Can you send them again please?

one comment inline.

Thanks
  Sascha

On Thu, Dec 11, 2008 at 02:14:41PM +0100, frederic Rodo wrote:
> Signed-off-by:Frederic Rodo 
> ---
>  drivers/nand/nand_imx.c |   94
> +--
>  include/asm-arm/arch-imx/imx-nand.h |2 +-
>  2 files changed, 79 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/nand/nand_imx.c b/drivers/nand/nand_imx.c
> index f7f50b0..3bf67de 100644
> --- a/drivers/nand/nand_imx.c
> +++ b/drivers/nand/nand_imx.c
> @@ -1090,26 +1090,74 @@ static struct driver_d imx_nand_driver = {
>  
>  static void __nand_boot_init nfc_addr(struct imx_nand_host *host, u32 offs)
>  {
> -send_addr(host, offs & 0xff);
> -send_addr(host, (offs >> 9) & 0xff);
> -send_addr(host, (offs >> 17) & 0xff);
> -send_addr(host, (offs >> 25) & 0xff);
> +if (!host->pagesize_2k) {

Can you turn this into positive logic?

> +send_addr(host, offs & 0xff);
> +send_addr(host, (offs >> 9) & 0xff);
> +send_addr(host, (offs >> 17) & 0xff);
> +send_addr(host, (offs >> 25) & 0xff);
> +} else {
> +/* imx27 Nand flash controller can only read full 2k page */
> +send_addr(host, 0);
> +send_addr(host, 0);
> +send_addr(host, (offs >> 11) & 0xff);
> +send_addr(host, (offs >> 19) & 0xff);
> +/* FIXME: add another send_addr for nandflash > 1Gbit
> + * if (read electronic signature byte 5 > 1 Gbit)
> + *send_addr(host, (offs >> 28) & 0xff);
> + */
> +
> +/* send read start command */
> +send_cmd(host, NAND_CMD_READSTART);
> +}
>  }
>  
> -static int __nand_boot_init block_is_bad(struct imx_nand_host *host,
> u32 offs)
> +static int __nand_boot_init block_is_bad(struct imx_nand_host *host,
> u32 offs,
> + u32 pagesize)
>  {
> -send_cmd(host, NAND_CMD_READOOB);
> -nfc_addr(host, offs);
> -send_read_page(host, 0, 1);
> -
> -return (readw(host->regs + SPARE_AREA0) & 0xff) == 0xff ? 0 : 1;
> +if (!host->pagesize_2k) {

dito

> +send_cmd(host, NAND_CMD_READOOB);
> +nfc_addr(host, offs);
> +send_read_page(host, 0, 1);
> +if ((readw(host->regs + SPARE_AREA0) & 0xff) != 0xff)
> +return 1;
> +} else {
> +/* The AdvancedToolKit Mark the two first page of each block */
> +/* check first page */
> +send_cmd(host, NAND_CMD_READ0);
> +nfc_addr(host, offs);
> +send_read_page(host, 0, 1);
> +send_read_page(host, 1, 1);
> +send_read_page(host, 2, 1);
> +send_read_page(host, 3, 1);
> +
> +if (readw(host->regs + NFC_ECC_STATUS_RESULT) & 0xa)
> +return 1;
> +
> +if ((readw(host->regs + SPARE_AREA0 + 4) & 0xFF00) != 0xFF00)
> +return 1;
> +
> +/* check second page */
> +send_cmd(host, NAND_CMD_READ0);
> +nfc_addr(host, offs + pagesize);
> +send_read_page(host, 0, 1);
> +send_read_page(host, 1, 1);
> +send_read_page(host, 2, 1);
> +send_read_page(host, 3, 1);
> +
> +if (readw(host->regs + NFC_ECC_STATUS_RESULT) & 0xa)
> +return 1;
> +
> +if ((readw(host->regs + SPARE_AREA0 + 4) & 0xFF00) != 0xFF00)
> +return 1;
> +   
> +}
> +return 0;
>  }
>  
> -void __nand_boot_init imx_nand_load_image(void *dest, int size, int
> pagesize,
> -int blocksize)
> +void __nand_boot_init imx_nand_load_image(void *dest, int size, int
> blocksize)
>  {
>  struct imx_nand_host host;
> -u32 tmp, page, block;
> +u32 tmp, page, block, pagesize;
>  
>  PCCR1 |= PCCR1_NFC_BAUDEN;
>  
> @@ -1117,6 +1165,10 @@ void __nand_boot_init imx_nand_load_image(void
> *dest, int size, int pagesize,
>  case GPCR_BOOT_8BIT_NAND_2k:
>  case GPCR_BOOT_16BIT_NAND_2k:
>  host.pagesize_2k = 1;
> +pagesize = 2048;
> +break;
> +default:
> +pagesize = 512;
>  }
>  
>  host.regs = (void __iomem *)IMX_NFC_BASE;
> @@ -1134,14 +1186,19 @@ void __nand_boot_init imx_nand_load_image(void
> *dest, int size, int pagesize,
>  /* Unlock Block Command for given address range */
>  writew(0x4, host.regs + NFC_WRPROT);
>  
> +/* clear all operation  */
> +writew(0x8000, host.regs + NFC_CONFIG1);
> +
> +/* enable ECC, disable spare only and interrupt */
>  tmp = readw(host.regs + NFC_CONFIG1);
> -tmp |= NFC_ECC_EN;
> +tmp |= NFC_ECC_EN | NFC_INT_MSK;
> +tmp &= ~ NFC_SP_EN;
>  writew(tmp, host.regs + NFC_CONFIG1);
>  
>  block = page = 0;
>  
>  while (1) {
> -if (!block_is_bad(&host, block * blocksize)) {
> +if (!block_is_bad(&host, block * blocksize, pagesize)) {
>  page = 0;
>  while (pa

Re: [U-Boot] u-boot for imx27 Board

2008-08-21 Thread Sascha Hauer 
On Thu, Aug 21, 2008 at 06:54:53PM +0530, Lejin K Joy wrote:
> 
> Thanks a lot Sascha,
> 
> I was able to downlaod it and  I was compiling it. If you have worked on the
> same platform kindly give your valuable inputs.
> 
> I am compiling the U-boot for imx27ads board.

I just updated mx27ads support and added a defconfig file, so please do
a 'git pull'.

> 
> I have set the env variables using  the following commands : 
> 
> #ln -s arm cross_arch[I also tried setting it to machi-imx. This
> also is not helping]
> #ln -s arm cross_compile

Sorry, documentation is a bit outdated here, the links do not work any
more. You have to specify architecture and cross compiler on the command
line:

ARCH=arm CROSS_COMPILE=/whereever/it/is/arm-..-gcc make mx27ads_defconfig
ARCH=arm CROSS_COMPILE=/whereever/it/is/arm-..-gcc make menuconfig
ARCH=arm CROSS_COMPILE=/whereever/it/is/arm-..-gcc make

This should give you a uboot.bin which you can try on your board. If you
already have a bootloader (redboot?) on your board which you want to
keep, it's best to start U-Boot from RAM first. Load it somewhere to RAM
and jump there (don't know how to do this with redboot though).

Regards,
  Sascha


-- 
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot for imx27 Board

2008-08-21 Thread Sascha Hauer 
On Thu, Aug 21, 2008 at 02:35:43PM +0530, Lejin K Joy wrote:
> Hi,
> 
>  
> 
> I was trying to use u-boot for imx27 board. But I was not able to find uboot
> for the same board. Only one available is
>  u-boot/u-boot-v2.git
> but I was not able to download the same using the git tool. Any help would
> be appreciated.

Try

# git clone git://git.denx.de/u-boot-v2.git

or if you are behind a firewall

# git clone http://git.denx.de/u-boot-v2.git

might help

Sascha


-- 
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot