Support for the DENX M28 SoM

This patch supports:
- Timers
- Debug UART
- Clock

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

This patch supports:
- Timers
- Debug UART
- Clock

Quoted 4 lines · Marek Vasut

This patch supports:
- Timers
- Debug UART
- Clock

Hi Marek,

/opt/tools/bin/checkpatch.pl --no-tree ~/Desktop/U-Boot-01-15-V3-iMX28-Initial-support-for-iMX28-CPU.patch
WARNING: line over 80 characters
#634: FILE: arch/arm/cpu/arm926ejs/mx28/mx28.c:150:
+int do_mx28_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

total: 0 errors, 1 warnings, 4527 lines checked

Can you fix and resubmit ?

Stefano

the patch is big and will need approval to be let into ML. Removing the space in char * const argv[] shall do the trick, can you please do that by hand ?

Hi Stefano,

the patch is big and will need approval to be let into ML. Removing the space in char * const argv[] shall do the trick, can you please do that by hand ?

Quoted 5 lines · Marek Vasut

Hi Stefano,

the patch is big and will need approval to be let into ML. Removing the space in char * const argv[] shall do the trick, can you please do that by hand ?

I have absolutely no intention to push patches without beeing reviewed by ML, but I would like to prepare a branch with all your M28 patches to check consistency with the rest of code.

Running checkpatch on your patches I see a lot of issues, and not only a couple of them.

For example,

WARNING: line over 80 characters
#632: FILE: arch/arm/cpu/arm926ejs/mx28/mx28.c:150:
+int do_mx28_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

WARNING: line over 80 characters
#5415: FILE: arch/arm/include/asm/arch-mx28/iomux-mx28.h:23:
+ *
BANK PIN MUX

WARNING: line over 80 characters
#5418: FILE: arch/arm/include/asm/arch-mx28/iomux-mx28.h:26:
+#define MX28_PAD_GPMI_D00__GPMI_D0 MXS_IOMUX_PAD_NAKED(0, 0, PAD_MUXSEL_0)

Running checkpatch on all your patches I get 488 warnings. Can you check and fix them ?

Stefano

Quoted 10 lines

Running checkpatch on your patches I see a lot of issues, and not only a couple of them.

For example,

WARNING: line over 80 characters
#632: FILE: arch/arm/cpu/arm926ejs/mx28/mx28.c:150:
+int do_mx28_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

those iomux-mx28.h issues were already explained. It's a file taken from linux kernel with no modifications, that's why the issues. And if you take a look inside, fixing it would make it unreadable.

Dear Marek Vasut,

Quoted 10 lines · In message <[email protected]> you wrote:

Quoted 9 lines

Running checkpatch on your patches I see a lot of issues, and not only a couple of them.

For example,

WARNING: line over 80 characters
#632: FILE: arch/arm/cpu/arm926ejs/mx28/mx28.c:150:
+int do_mx28_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])

Quoted 3 lines

those iomux-mx28.h issues were already explained. It's a file taken from linux kernel with no modifications, that's why the issues. And if you take a look inside, fixing it would make it unreadable.

The error above appears to be unrelated. Why did you not fix at least these?

This patch supports:
- Timers
- Debug UART
- Clock

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---
 arch/arm/cpu/arm926ejs/mx28/Makefile          |   46 +
 arch/arm/cpu/arm926ejs/mx28/clock.c           |  355 +++++++
 arch/arm/cpu/arm926ejs/mx28/mx28.c            |  194 ++++
 arch/arm/cpu/arm926ejs/mx28/timer.c           |  141 +++
 arch/arm/include/asm/arch-mx28/clock.h        |   61 ++
 arch/arm/include/asm/arch-mx28/imx-regs.h     |   38 +
 arch/arm/include/asm/arch-mx28/regs-base.h    |   88 ++
 arch/arm/include/asm/arch-mx28/regs-bch.h     |  230 +++++
 arch/arm/include/asm/arch-mx28/regs-clkctrl.h |  312 ++++++
 arch/arm/include/asm/arch-mx28/regs-common.h  |   66 ++
 arch/arm/include/asm/arch-mx28/regs-gpmi.h    |  222 +++++
 arch/arm/include/asm/arch-mx28/regs-i2c.h     |  207 ++++
 arch/arm/include/asm/arch-mx28/regs-ocotp.h   |  173 ++++
 arch/arm/include/asm/arch-mx28/regs-pinctrl.h | 1284 +++++++++++++++++++++++++
 arch/arm/include/asm/arch-mx28/regs-power.h   |  413 ++++++++
 arch/arm/include/asm/arch-mx28/regs-rtc.h     |  147 +++
 arch/arm/include/asm/arch-mx28/regs-ssp.h     |  349 +++++++
 arch/arm/include/asm/arch-mx28/regs-timrot.h  |  171 ++++
 arch/arm/include/asm/arch-mx28/sys_proto.h    |   30 +
 19 files changed, 4527 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/Makefile
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/clock.c
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/mx28.c
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/timer.c
 create mode 100644 arch/arm/include/asm/arch-mx28/clock.h
 create mode 100644 arch/arm/include/asm/arch-mx28/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-base.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-bch.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-clkctrl.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-common.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-gpmi.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-i2c.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-ocotp.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-pinctrl.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-power.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-rtc.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-ssp.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-timrot.h
 create mode 100644 arch/arm/include/asm/arch-mx28/sys_proto.h

Dear Marek Vasut,

In message <[email protected]> you

Quoted 51 lines

This patch supports:
- Timers
- Debug UART
- Clock

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

 arch/arm/cpu/arm926ejs/mx28/Makefile          |   46 +
 arch/arm/cpu/arm926ejs/mx28/clock.c           |  355 +++++++
 arch/arm/cpu/arm926ejs/mx28/mx28.c            |  194 ++++
 arch/arm/cpu/arm926ejs/mx28/timer.c           |  141 +++
 arch/arm/include/asm/arch-mx28/clock.h        |   61 ++
 arch/arm/include/asm/arch-mx28/imx-regs.h     |   38 +
 arch/arm/include/asm/arch-mx28/regs-base.h    |   88 ++
 arch/arm/include/asm/arch-mx28/regs-bch.h     |  230 +++++
 arch/arm/include/asm/arch-mx28/regs-clkctrl.h |  312 ++++++
 arch/arm/include/asm/arch-mx28/regs-common.h  |   66 ++
 arch/arm/include/asm/arch-mx28/regs-gpmi.h    |  222 +++++
 arch/arm/include/asm/arch-mx28/regs-i2c.h     |  207 ++++
 arch/arm/include/asm/arch-mx28/regs-ocotp.h   |  173 ++++
 arch/arm/include/asm/arch-mx28/regs-pinctrl.h | 1284
 +++++++++++++++++++++++++ arch/arm/include/asm/arch-mx28/regs-power.h  
 |  413 ++++++++
 arch/arm/include/asm/arch-mx28/regs-rtc.h     |  147 +++
 arch/arm/include/asm/arch-mx28/regs-ssp.h     |  349 +++++++
 arch/arm/include/asm/arch-mx28/regs-timrot.h  |  171 ++++
 arch/arm/include/asm/arch-mx28/sys_proto.h    |   30 +
 19 files changed, 4527 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/Makefile
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/clock.c
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/mx28.c
 create mode 100644 arch/arm/cpu/arm926ejs/mx28/timer.c
 create mode 100644 arch/arm/include/asm/arch-mx28/clock.h
 create mode 100644 arch/arm/include/asm/arch-mx28/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-base.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-bch.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-clkctrl.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-common.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-gpmi.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-i2c.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-ocotp.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-pinctrl.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-power.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-rtc.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-ssp.h
 create mode 100644 arch/arm/include/asm/arch-mx28/regs-timrot.h
 create mode 100644 arch/arm/include/asm/arch-mx28/sys_proto.h

...

arch/arm/cpu/arm926ejs/mx28/mx28.c line 36

Quoted 8 lines

arch/arm/cpu/arm926ejs/mx28/mx28.c new file +8 -0

+#include <common.h>
+#include <asm/errno.h>
+#include <asm/io.h>
+#include <asm/arch/clock.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/imx-regs.h>
+#include <asm/arch/sys_proto.h>
+#include <asm/arch/iomux-mx28.h>

You include <asm/arch/iomux-mx28.h> here, but add this file only in patch # 4 of your series. That means your patches are not bisectable.

Signed-off-by Marek Vasut <[email protected]>

Cc Ben Warren <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

 drivers/net/fec_mxc.c |   44 ++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 42 insertions(+), 2 deletions(-)

drivers/net/fec_mxc.c +0 -0

index cfe2176..f50433dd 100644
@@ -42,6 +42,14 @@ DECLARE_GLOBAL_DATA_PTR;
 #define	CONFIG_FEC_XCV_TYPE	MII100

Quoted 6 lines · Marek Vasut

Signed-off-by Marek Vasut <[email protected]>

Cc Ben Warren <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

Hi Marek,

only a small question:

Quoted 13 lines

 drivers/net/fec_mxc.c |   44

++++++++++++++++++++++++++++++++++++++++++-- 1 files changed, 42 insertions(+), 2 deletions(-)

drivers/net/fec_mxc.c +0 -0

index cfe2176..f50433dd 100644
@@ -42,6 +42,14 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define	CONFIG_FEC_XCV_TYPE	MII100
 #endif
 

drivers/net/fec_mxc.c DECLARE_GLOBAL_DATA_PTR; · line 52

Quoted 8 lines

drivers/net/fec_mxc.c +2 -0

+/*
+ * The i.MX28 operates with packets in big endian. We need to swap them

before + * sending and after receiving.
+ */

drivers/net/fec_mxc.c +4 -0

+#ifdef	CONFIG_MX28
+#define	CONFIG_FEC_MXC_SWAP_PACKET
+#endif
+

Do we really need two defines ? If the MX28 has the oddity to swap packets and this must be always done for this SOC, we could protect the code only with CONFIG_MX28. I think in the code it is already clear that in case of MX28 the packets are swapped.

Best regards,
Stefano Babic

Quoted 4 lines · Stefano Babic

Quoted 3 lines · Marek Vasut

drivers/net/fec_mxc.c +0 -0

Quoted 12 lines

drivers/net/fec_mxc.c

Quoted 7 lines

+/*
+ * The i.MX28 operates with packets in big endian. We need to swap them before + * sending and after receiving.
+ */

drivers/net/fec_mxc.c +3 -0

+#ifdef ? ? CONFIG_MX28
+#define ? ?CONFIG_FEC_MXC_SWAP_PACKET
+#endif

Do we really need two defines ? If the MX28 has the oddity to swap packets and this must be always done for this SOC, we could protect the code only with CONFIG_MX28. I think in the code it is already clear that in case of MX28 the packets are swapped.

Well if any other CPU with this problem pops up on the market, we should be ready.

Signed-off-by Marek Vasut <[email protected]>

Cc Heiko Schocher <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---
 drivers/i2c/Makefile  |    1 +
 drivers/i2c/mxs_i2c.c |  240 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 241 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/mxs_i2c.c

Hello Marek,

Quoted 5 lines · Marek Vasut

Signed-off-by Marek Vasut <[email protected]>

Cc Heiko Schocher <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

Quoted 7 lines

---

 drivers/i2c/Makefile  |    1 +
 drivers/i2c/mxs_i2c.c |  240
 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 241
 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/mxs_i2c.c

Hmm I see you worked in my comment, but then your subject line should contain a "v2", and also a short description, what you changed, would be nice ... also, patchwork did not recognize, that this patch is a following up to your first version. When sending patchupdates, you should use your first Message-id, so patchwork could follow it.

bye,
Heiko

Signed-off-by Marek Vasut <[email protected]>

Cc Heiko Schocher <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---
 drivers/i2c/Makefile  |    1 +
 drivers/i2c/mxs_i2c.c |  240 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 241 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/mxs_i2c.c

drivers/i2c/Makefile +1 -0

index a48047a..2fb521e 100644
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
 COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
 COBJS-$(CONFIG_I2C_MV) += mv_i2c.o
 COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
+COBJS-$(CONFIG_I2C_MXS) += mxs_i2c.o
 COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
 COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
 COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o

drivers/i2c/mxs_i2c.c new file +0 -0

new file mode 100644
index 0000000..9f380a0

Hi Marek,

Quoted 29 lines · Marek Vasut

Signed-off-by Marek Vasut <[email protected]>

Cc Heiko Schocher <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

 drivers/i2c/Makefile  |    1 +
 drivers/i2c/mxs_i2c.c |  240
 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 241
 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/mxs_i2c.c

drivers/i2c/Makefile +1 -0

index a48047a..2fb521e 100644
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
 
 COBJS-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
 COBJS-$(CONFIG_I2C_MV) += mv_i2c.o
 COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
 
+COBJS-$(CONFIG_I2C_MXS) += mxs_i2c.o
 

COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o

drivers/i2c/mxs_i2c.c line 5

Quoted 11 lines

drivers/i2c/mxs_i2c.c new file +5 -0

new file mode 100644
index 0000000..9f380a0
@@ -0,0 +1,240 @@
+/*
+ * Freescale i.MX28 I2C Driver
+ *
+ * Copyright (C) 2011 Marek Vasut <[email protected]>
+ * on behalf of DENX Software Engineering GmbH

Do you mind adding the copyrights from the kernel driver here? It looks quite inspired to me, even if you didn't like some of the variable names and defines :)

Regards,

Wolfram

Quoted 7 lines

Quoted 7 lines

drivers/i2c/mxs_i2c.c new file +1 -0

new file mode 100644
index 0000000..9f380a0
@@ -0,0 +1,240 @@
+/*

Quoted 8 lines

drivers/i2c/mxs_i2c.c line 5

Quoted 4 lines

drivers/i2c/mxs_i2c.c new file +4 -0

+ * Freescale i.MX28 I2C Driver
+ *
+ * Copyright (C) 2011 Marek Vasut <[email protected]>
+ * on behalf of DENX Software Engineering GmbH

Do you mind adding the copyrights from the kernel driver here? It looks quite inspired to me, even if you didn't like some of the variable names and defines :)

Bits are from the STMP3xxx driver, not much though.

Quoted 16 lines

Quoted 7 lines

Quoted 7 lines

drivers/i2c/mxs_i2c.c new file +1 -0

new file mode 100644
index 0000000..9f380a0
@@ -0,0 +1,240 @@
+/*

Quoted 8 lines

drivers/i2c/mxs_i2c.c line 5

Quoted 4 lines

drivers/i2c/mxs_i2c.c new file +4 -0

+ * Freescale i.MX28 I2C Driver
+ *
+ * Copyright (C) 2011 Marek Vasut <[email protected]>
+ * on behalf of DENX Software Engineering GmbH

Do you mind adding the copyrights from the kernel driver here? It looks quite inspired to me, even if you didn't like some of the variable names and defines :)

Quoted 1 line

Bits are from the STMP3xxx driver, not much though.

Could you point me to that driver? Maybe it needs fixing as well, because that pattern for example:

drivers/i2c/mxs_i2c.c new file +11 -0

+       off = i;
+       for (; i < off + blen; i++) {
+               data >>= 8;
+               data |= buf[i - off] << 24;
+               if ((i & 3) == 2)
+                       writel(data, &i2c_regs->hw_i2c_data);
+       }
+
+       remain = 24 - ((i & 3) * 8);
+       if (remain)
+               writel(data >> remain, &i2c_regs->hw_i2c_data);

is highly similar to my reimplementation of the "let's feed the buffer code" in the kernel (to name one example). Check current linus-git:

        for (i = 0; i < len; i++) {
                data >>= 8;
                data |= buf[i] << 24;
                if ((i & 3) == 2)
                        writel(data, i2c->regs + MXS_I2C_DATA);
        }

        /* Write out the remaining bytes if any */
        shifts_left = 24 - (i & 3) * 8;
        if (shifts_left)
                writel(data >> shifts_left, i2c->regs + MXS_I2C_DATA);

I'd be very surprised if two programmers would come up with two routines that equal?

Regards,

Wolfram

Oh I2C, not SPI. Sorry.

Will add Based on line, cheers!

Signed-off-by Marek Vasut <[email protected]>

Cc Stefano Babic <[email protected]>

Cc Wolfgang Denk <[email protected]>

Cc Detlev Zundel <[email protected]>

---

drivers/gpio/mxs_gpio.c new file +17 -0

+
+#include <common.h>
+#include <netdev.h>
+#include <asm/errno.h>
+#include <asm/io.h>
+#include <asm/arch/iomux.h>
+#include <asm/arch/imx-regs.h>
+
+#if	defined(CONFIG_MX23)
+#define	PINCTRL_BANKS		3
+#define	PINCTRL_DOUT(n)		(0x0500 + ((n) * 0x10))
+#define	PINCTRL_DIN(n)		(0x0600 + ((n) * 0x10))
+#define	PINCTRL_DOE(n)		(0x0700 + ((n) * 0x10))
+#define	PINCTRL_PIN2IRQ(n)	(0x0800 + ((n) * 0x10))
+#define	PINCTRL_IRQEN(n)	(0x0900 + ((n) * 0x10))
+#define	PINCTRL_IRQSTAT(n)	(0x0c00 + ((n) * 0x10))
+#elif	defined(CONFIG_MX28)

drivers/spi/mxs_spi.c new file +6 -0

+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int mode)
+{
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+

Quoted 10 lines · On Monday, September 12, 2011 00:06:41 Marek Vasut wrote:

drivers/spi/mxs_spi.c new file +10 -0

+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int mode)
+{
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+
+	writel(SSP_CTRL0_BUS_WIDTH_ONE_BIT, &ssp_regs->hw_ssp_ctrl0);
+
+	reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
+	reg |= (mode & SPI_CPOL) ? SSP_CTRL1_POLARITY : 0;

drivers/spi/mxs_spi.c line 78

Quoted 6 lines

drivers/spi/mxs_spi.c new file +6 -0

+	reg |= (mode & SPI_CPHA) ? SSP_CTRL1_PHASE : 0;
+	writel(reg, &ssp_regs->hw_ssp_ctrl1);
+
+	writel(0, &ssp_regs->hw_ssp_cmd0);
+
+	mx28_set_ssp_busclock(bus, max_hz / 1000);

these steps should be done in the claim_bus func

drivers/spi/mxs_spi.c line 104

Quoted 3 lines

drivers/spi/mxs_spi.c new file +2 -0

+void mxs_spi_start_xfer(struct spi_slave *slave)
+void mxs_spi_end_xfer(struct spi_slave *slave)

both should be static
-mike

Quoted 11 lines · Mike Frysinger

Quoted 10 lines · On Monday, September 12, 2011 00:06:41 Marek Vasut wrote:

drivers/spi/mxs_spi.c new file +10 -0

+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int mode)
+{
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+
+	writel(SSP_CTRL0_BUS_WIDTH_ONE_BIT, &ssp_regs->hw_ssp_ctrl0);
+
+	reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
+	reg |= (mode & SPI_CPOL) ? SSP_CTRL1_POLARITY : 0;

Quoted 8 lines

drivers/spi/mxs_spi.c line 78

Quoted 6 lines

drivers/spi/mxs_spi.c new file +6 -0

+	reg |= (mode & SPI_CPHA) ? SSP_CTRL1_PHASE : 0;
+	writel(reg, &ssp_regs->hw_ssp_ctrl1);
+
+	writel(0, &ssp_regs->hw_ssp_cmd0);
+
+	mx28_set_ssp_busclock(bus, max_hz / 1000);

these steps should be done in the claim_bus func

I don't think so ... I need to access max_hz and mode. This seems more fitting to me.

Quoted 4 lines · On Monday, September 12, 2011 13:42:22 Marek Vasut wrote:

Quoted 3 lines · Mike Frysinger

Review

Quoted 2 lines · On Monday, September 12, 2011 00:06:41 Marek Vasut wrote:

(quoted diff) +2 -0

+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+				  unsigned int max_hz, unsigned int 

Quoted 17 lines

Quoted 8 lines

Quoted 8 lines

drivers/spi/mxs_spi.c new file +8 -0

+{
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+
+	writel(SSP_CTRL0_BUS_WIDTH_ONE_BIT, &ssp_regs->hw_ssp_ctrl0);
+
+	reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
+	reg |= (mode & SPI_CPOL) ? SSP_CTRL1_POLARITY : 0;

Quoted 8 lines

drivers/spi/mxs_spi.c line 78

Quoted 6 lines

drivers/spi/mxs_spi.c new file +6 -0

+	reg |= (mode & SPI_CPHA) ? SSP_CTRL1_PHASE : 0;
+	writel(reg, &ssp_regs->hw_ssp_ctrl1);
+
+	writel(0, &ssp_regs->hw_ssp_cmd0);
+
+	mx28_set_ssp_busclock(bus, max_hz / 1000);

these steps should be done in the claim_bus func

Quoted 2 lines

I don't think so ... I need to access max_hz and mode. This seems more fitting to me.

that's not how the API works. you create clients, then you acquire the bus for a specific client, do a transfer, and then release it. your bus breaks with the trivial case:
- setup slave A
- setup slave B
- claim bus for slave A
- transfer with slave A <- uses settings from slave B
-mike

drivers/spi/mxs_spi.c new file +8 -0

+int spi_claim_bus(struct spi_slave *slave)
+{
+	struct mxs_spi_slave *mxs_slave = to_mxs_slave(slave);
+	struct mx28_ssp_regs *ssp_regs = mxs_slave->regs;
+	uint32_t reg = 0;
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+

Quoted 12 lines · On Tuesday, September 13, 2011 18:26:19 Marek Vasut wrote:

drivers/spi/mxs_spi.c new file +12 -0

+int spi_claim_bus(struct spi_slave *slave)
+{
+	struct mxs_spi_slave *mxs_slave = to_mxs_slave(slave);
+	struct mx28_ssp_regs *ssp_regs = mxs_slave->regs;
+	uint32_t reg = 0;
+
+	mx28_reset_block(&ssp_regs->hw_ssp_ctrl0_reg);
+
+	writel(SSP_CTRL0_BUS_WIDTH_ONE_BIT, &ssp_regs->hw_ssp_ctrl0);
+
+	reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
+	reg |= (mxs_slave->mode & SPI_CPOL) ? SSP_CTRL1_POLARITY : 0;

drivers/spi/mxs_spi.c line 103

Quoted 6 lines

drivers/spi/mxs_spi.c new file +6 -0

+	reg |= (mxs_slave->mode & SPI_CPHA) ? SSP_CTRL1_PHASE : 0;
+	writel(reg, &ssp_regs->hw_ssp_ctrl1);
+
+	writel(0, &ssp_regs->hw_ssp_cmd0);
+
+	mx28_set_ssp_busclock(slave->bus, mxs_slave->max_khz);

this turns on the hardware ...

drivers/spi/mxs_spi.c line 110

Quoted 4 lines

drivers/spi/mxs_spi.c new file +3 -0

+void spi_release_bus(struct spi_slave *slave)
+{
+}

... so shouldn't this turn it off ?

i dont have the datasheet for the controller, so i have no idea :) -mike

+/*
+ * There are several places in this driver where we have to handle the OOB and
+ * block marks. This is the function where things are the most complicated, so
+ * this is where we try to explain it all. All the other places refer back to
+ * here.
+ *
+ * These are the rules, in order of decreasing importance:
+ *
+ * 1) Nothing the caller does can be allowed to imperil the block mark, so all
+ * write operations take measures to protect it.
+ *
+ * 2) In read operations, the first byte of the OOB we return must reflect the
+ * true state of the block mark, no matter where that block mark appears in
+ * the physical page.
+ *
+ * 3) ECC-based read operations return an OOB full of set bits (since we never
+ * allow ECC-based writes to the OOB, it doesn't matter what ECC-based reads
+ * return).
+ *
+ * 4) "Raw" read operations return a direct view of the physical bytes in the

+ *    page, using the conventional definition of which bytes are data and which
+ *    are OOB. This gives the caller a way to see the actual, physical bytes
+ *    in the page, without the distortions applied by our ECC engine.

+ * It turns out that knowing whether we want an "ECC-based" or "raw" read is not
+ * easy. When reading a page, for example, the NAND Flash MTD code calls our
+ * ecc.read_page or ecc.read_page_raw function. Thus, the fact that MTD wants an
+ * ECC-based or raw view of the page is implicit in which function it calls
+ * (there is a similar pair of ECC-based/raw functions for writing).

drivers/mtd/nand/mxs_nand.c new file +7 -0

+/*
+ * Write OOB data to NAND.
+ */
+static int mxs_nand_ecc_write_oob(struct mtd_info *mtd, struct nand_chip *nand,
+					int page)
+{
+	struct mxs_nand_info *nand_info = nand->priv;

drivers/mtd/nand/mxs_nand.c new file +10 -0

+/*
+ * Claims all blocks are good.
+ *
+ * In principle, this function is *only* called when the NAND Flash MTD system
+ * isn't allowed to keep an in-memory bad block table, so it is forced to ask
+ * the driver for bad block information.
+ *
+ * In fact, we permit the NAND Flash MTD system to have an in-memory BBT, so
+ * this function is *only* called when we take it away.
+ *

+/*
+ * Nominally, the purpose of this function is to look for or create the bad
+ * block table. In fact, since the HIL calls this function at the very end of

+ * the initialization process started by nand_scan(), and the HIL doesn't have a
+ * more formal mechanism, everyone "hooks" this function to continue the
+ * initialization process.

drivers/mtd/nand/mxs_nand.c line 96

Quoted 6 lines · Marek Vasut

drivers/mtd/nand/mxs_nand.c new file +6 -0

+static void mxs_nand_return_dma_descs(struct mxs_nand_info *info)
+{
+	int i = info->desc_index;
+	struct mxs_dma_desc *desc;
+
+	for (--i; i >= 0; i--) {

This is an awkward construct.

Why not just the usual:

for (i = 0; i < info->desc_index; i++)

drivers/mtd/nand/mxs_nand.c line 108

Quoted 13 lines

drivers/mtd/nand/mxs_nand.c new file +12 -0

+		desc = info->desc[i];
+		memset(desc, 0, sizeof(struct mxs_dma_desc));
+		desc->address = (dma_addr_t)desc;
+	}
+
+	info->desc_index = 0;
+}
+
+static inline uint32_t mxs_nand_ecc_chunk_cnt(uint32_t page_data_size)
+{
+	return page_data_size / MXS_NAND_CHUNK_DATA_CHUNK_SIZE;
+}

No need for inline in .c files, GCC should take care of this automatically.

Quoted 17 lines

+/*
+ * There are several places in this driver where we have to handle the OOB and + * block marks. This is the function where things are the most complicated, so + * this is where we try to explain it all. All the other places refer back to + * here.
+ *
+ * These are the rules, in order of decreasing importance:
+ *
+ * 1) Nothing the caller does can be allowed to imperil the block mark,
so all + * write operations take measures to protect it.
+ *
+ * 2) In read operations, the first byte of the OOB we return must
reflect the + * true state of the block mark, no matter where that
block mark appears in + * the physical page.
+ *
+ * 3) ECC-based read operations return an OOB full of set bits (since we

Quoted 8 lines

never + * allow ECC-based writes to the OOB, it doesn't matter what
ECC-based reads + * return).
+ *
+ * 4) "Raw" read operations return a direct view of the physical bytes
in the + * page, using the conventional definition of which bytes are
data and which + * are OOB. This gives the caller a way to see the
actual, physical bytes + * in the page, without the distortions
applied by our ECC engine.

Hmm, I thought raw was just supposed to disable ECC, not change the layout from what is used in normal operation.

Quoted 7 lines

+ * It turns out that knowing whether we want an "ECC-based" or "raw" read is not + * easy. When reading a page, for example, the NAND Flash MTD code calls our + * ecc.read_page or ecc.read_page_raw function. Thus, the fact that MTD wants an + * ECC-based or raw view of the page is implicit in which function it calls + * (there is a similar pair of ECC-based/raw functions for writing).

This is an issue for the eLBC driver as well -- we need to know whether to enable or disable ECC before we begin the operation (in cmdfunc), not just at the time the buffer is accessed. Currently we just always have ECC on, and raw accesses aren't raw. It would be nice to fix this more generally (starting in Linux, so we don't diverge).

It's too bad we can't rely on chip->ops being used... maybe we could copy the data into there? Or just have a separate mtd_oob_mode_t in nand_chip.

Quoted 11 lines

drivers/mtd/nand/mxs_nand.c new file +4 -0

+/*
+ * Write OOB data to NAND.
+ */
+static int mxs_nand_ecc_write_oob(struct mtd_info *mtd, struct nand_chip

*nand, + int page)

drivers/mtd/nand/mxs_nand.c new file +6 -0

+{
+	struct mxs_nand_info *nand_info = nand->priv;
+	uint8_t block_mark = 0;
+
+	/*
+	 * There are fundamental incompatibilities between the i.MX GPMI NFC

Quoted 1 line

and + * the NAND Flash MTD model that make it essentially impossible

drivers/mtd/nand/mxs_nand.c line 907

Quoted 5 lines

write + * the out-of-band bytes.

drivers/mtd/nand/mxs_nand.c new file +4 -0

+	 *
+	 * We permit *ONE* exception. If the *intent* of writing the OOB is to
+	 * mark a block bad, we can do that.
+	 */

Is this just an issue with writing OOB separately from the main data (which would also be an issue on MLC chips that don't allow multiple partial programming), or can you not even write user OOB bytes as part of a full page write?

Based on fake_ecc_layout I'm guessing the latter.

drivers/mtd/nand/mxs_nand.c line 912

Quoted 5 lines

drivers/mtd/nand/mxs_nand.c new file +4 -0

+	if (nand_info->marking_block_bad) {
+		printf("NXS NAND: Writing OOB isn't supported\n");
+		return -EIO;
+	}

Shouldn't this be if (!nand_info->marking_block_bad)?

Quoted 14 lines

+/*
+ * Claims all blocks are good.
+ *
+ * In principle, this function is *only* called when the NAND Flash MTD system + * isn't allowed to keep an in-memory bad block table, so it is forced to ask + * the driver for bad block information.
+ *
+ * In fact, we permit the NAND Flash MTD system to have an in-memory BBT, so + * this function is *only* called when we take it away.
+ *
+ * We take away the in-memory BBT when the user sets the "ignorebad" parameter, + * which indicates that all blocks should be reported good.
+ *
+ * Thus, this function is only called when we want *all* blocks to look

Review

Quoted 6 lines

good, + * so it *always* return success.
+ */
+static int mxs_nand_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip) +{

(quoted diff) +2 -0

+	return 0;
+}

What/where is the "ignorebad" parameter?

Other than when scrubbing (which has its own override), when would you want to do this?

Quoted 4 lines

+/*
+ * Nominally, the purpose of this function is to look for or create the bad + * block table. In fact, since the HIL calls this function at the very end of

HIL?

Quoted 4 lines

+ * the initialization process started by nand_scan(), and the HIL doesn't have a + * more formal mechanism, everyone "hooks" this function to continue the + * initialization process.

Everyone? I only see diskonchip doing this.

The nand_base.c code actually does have a split here (nand_scan_ident/nand_scan_tail), but U-Boot's glue code is too inflexible, and insists on calling nand_scan. The right fix is to let drivers call nand_scan_ident/nand_scan_tail themselves.

-Scott

Quoted 15 lines · Scott Wood

drivers/mtd/nand/mxs_nand.c line 108

Quoted 12 lines · Marek Vasut

drivers/mtd/nand/mxs_nand.c new file +12 -0

+		desc = info->desc[i];
+		memset(desc, 0, sizeof(struct mxs_dma_desc));
+		desc->address = (dma_addr_t)desc;
+	}
+
+	info->desc_index = 0;
+}
+
+static inline uint32_t mxs_nand_ecc_chunk_cnt(uint32_t page_data_size)
+{
+	return page_data_size / MXS_NAND_CHUNK_DATA_CHUNK_SIZE;
+}

No need for inline in .c files, GCC should take care of this automatically.

Does it really ?

Quoted 2 lines

Hmm, I thought raw was just supposed to disable ECC, not change the layout from what is used in normal operation.

You see the page as is ... I see no problem with this part.

* MTD_OOB_RAW: mode to read oob and data without doing ECC checking

 * MTD_OOB_RAW:         mode to read raw data+oob in one chunk. The oob data
 *                      is inserted into the data. Thats a raw image of the
 *                      flash contents.

Quoted 3 lines

Quoted 3 lines

(quoted diff) +2 -0

+	/*
+	 * There are fundamental incompatibilities between the i.MX GPMI NFC

and + * the NAND Flash MTD model that make it essentially impossible

to

Quoted 11 lines

drivers/mtd/nand/mxs_nand.c line 907

Quoted 5 lines

write + * the out-of-band bytes.

drivers/mtd/nand/mxs_nand.c new file +4 -0

+	 *
+	 * We permit *ONE* exception. If the *intent* of writing the OOB is to
+	 * mark a block bad, we can do that.
+	 */

Is this just an issue with writing OOB separately from the main data (which would also be an issue on MLC chips that don't allow multiple partial programming), or can you not even write user OOB bytes as part of a full page write?

Quoted 1 line

Based on fake_ecc_layout I'm guessing the latter.

My understanding of the original FSL driver is that you should never be allowed to access the physical NAND media at all. Only through the driver, which does the magic.

Quoted 4 lines

The nand_base.c code actually does have a split here (nand_scan_ident/nand_scan_tail), but U-Boot's glue code is too inflexible, and insists on calling nand_scan. The right fix is to let drivers call nand_scan_ident/nand_scan_tail themselves.

I can't test now, so this has to wait. I'd prefer to get this mainline and then start poking around fixing this.

Quoted 18 lines · Marek Vasut

Quoted 16 lines · Scott Wood

drivers/mtd/nand/mxs_nand.c line 108

Quoted 12 lines · Marek Vasut

drivers/mtd/nand/mxs_nand.c new file +12 -0

+		desc = info->desc[i];
+		memset(desc, 0, sizeof(struct mxs_dma_desc));
+		desc->address = (dma_addr_t)desc;
+	}
+
+	info->desc_index = 0;
+}
+
+static inline uint32_t mxs_nand_ecc_chunk_cnt(uint32_t page_data_size)
+{
+	return page_data_size / MXS_NAND_CHUNK_DATA_CHUNK_SIZE;
+}

No need for inline in .c files, GCC should take care of this automatically.

Quoted 1 line

Does it really ?

Very small functions (and anything used only once) get inlined automatically.

It might need the hint if you have a larger function that collapses down to something small due to constant propagation (and of course if it's a header or otherwise *must* be inlined), but usually it does a decent job on its own.

Quoted 4 lines

Quoted 2 lines

Hmm, I thought raw was just supposed to disable ECC, not change the layout from what is used in normal operation.

You see the page as is ... I see no problem with this part.

What if the raw access is being done to e.g. force bit flips for testing?

There seems to be a difference between U-Boot and Linux here.

Linux has this in mtd.h:

Quoted 2 lines

* MTD_OOB_RAW: mode to read oob and data without doing ECC
checking

Doesn't say anything about layout.

Whereas U-Boot says:

Quoted 3 lines

* MTD_OOB_RAW: mode to read raw data+oob in one chunk. The oob
data * is inserted into the data. Thats a raw
image of the * flash contents.

Linux used to say what U-Boot says, but changed in commit b64d39d8b03fea88417d53715ccbebf71d4dcc9f

This commit message includes the comment "Now MTD_OOB_RAW behaves just like MTD_OOB_PLACE, but doesn't do ECC validation".

So I think if you need something that changes the layout from normal operations, it needs to be a new mode. And it's about time to sync up U-Boot's NAND code with Linux again...

Quoted 18 lines

Quoted 4 lines

Quoted 4 lines

(quoted diff) +2 -0

+	/*
+	 * There are fundamental incompatibilities between the i.MX GPMI NFC

and + * the NAND Flash MTD model that make it essentially impossible

to

Quoted 11 lines

Review

Quoted 5 lines

write + * the out-of-band bytes.

(quoted diff) +2 -0

+	 *
+	 * We permit *ONE* exception. If the *intent* of writing the OOB is

to + * mark a block bad, we can do that.

(quoted diff) +1 -0

+	 */

Is this just an issue with writing OOB separately from the main data (which would also be an issue on MLC chips that don't allow multiple partial programming), or can you not even write user OOB bytes as part of a full page write?

Quoted 5 lines

Quoted 1 line

Based on fake_ecc_layout I'm guessing the latter.

My understanding of the original FSL driver is that you should never be allowed to access the physical NAND media at all. Only through the driver, which does the magic.

I'm not talking about circumventing the driver, just accessing some user OOB bytes through it.

Quoted 8 lines

Quoted 5 lines

The nand_base.c code actually does have a split here (nand_scan_ident/nand_scan_tail), but U-Boot's glue code is too inflexible, and insists on calling nand_scan. The right fix is to let drivers call nand_scan_ident/nand_scan_tail themselves.

I can't test now, so this has to wait. I'd prefer to get this mainline and then start poking around fixing this.

OK. It's been on my TODO list for a while now...

-Scott

Quoted 3 lines · Scott Wood

So I think if you need something that changes the layout from normal operations, it needs to be a new mode. And it's about time to sync up U-Boot's NAND code with Linux again...

Well aren't you the maintainer that should take care of it ? ;-)

Quoted 2 lines

I'm not talking about circumventing the driver, just accessing some user OOB bytes through it.

There are no user OOB bytes, the driver does the ECC so user has no need to write any OOB.

Quoted 6 lines · Marek Vasut

Quoted 3 lines · Scott Wood

So I think if you need something that changes the layout from normal operations, it needs to be a new mode. And it's about time to sync up U-Boot's NAND code with Linux again...

Well aren't you the maintainer that should take care of it ? ;-)

Yes, that note was me adding something to my todo list. :-)

Quoted 5 lines

Quoted 2 lines

I'm not talking about circumventing the driver, just accessing some user OOB bytes through it.

There are no user OOB bytes, the driver does the ECC so user has no need to write any OOB.

By "user OOB bytes" I meant things other than the ECC and the bad-block marker -- the space described by oobavail in ecclayout. This is getting less useful with partial-page restrictions and large ECC that fills up most of the OOB, though, and thus there's a trend away from making use of it. So if it's a pain to provide access to any spare OOB bytes, it's not that big of a deal.

-Scott

drivers/mtd/nand/mxs_nand.c line 96

Quoted 6 lines · Marek Vasut

drivers/mtd/nand/mxs_nand.c new file +6 -0

+static void mxs_nand_return_dma_descs(struct mxs_nand_info *info)
+{
+	int i = info->desc_index;
+	struct mxs_dma_desc *desc;
+
+	for (--i; i >= 0; i--) {

This is an awkward construct.

Why not just the usual:

for (i = 0; i < info->desc_index; i++)

Quoted 10 lines · Scott Wood

drivers/mtd/nand/mxs_nand.c line 96

Quoted 6 lines · Marek Vasut

drivers/mtd/nand/mxs_nand.c new file +6 -0

+static void mxs_nand_return_dma_descs(struct mxs_nand_info *info)
+{
+	int i = info->desc_index;
+	struct mxs_dma_desc *desc;
+
+	for (--i; i >= 0; i--) {

This is an awkward construct.

Quoted 4 lines

Why not just the usual:

for (i = 0; i < info->desc_index; i++)

Checking the driver, this modifies the global data so this is ok

+/*
+ * There are several places in this driver where we have to handle the OOB and
+ * block marks. This is the function where things are the most complicated, so
+ * this is where we try to explain it all. All the other places refer back to
+ * here.
+ *
+ * These are the rules, in order of decreasing importance:
+ *
+ * 1) Nothing the caller does can be allowed to imperil the block mark, so all
+ * write operations take measures to protect it.
+ *
+ * 2) In read operations, the first byte of the OOB we return must reflect the
+ * true state of the block mark, no matter where that block mark appears in
+ * the physical page.
+ *
+ * 3) ECC-based read operations return an OOB full of set bits (since we never
+ * allow ECC-based writes to the OOB, it doesn't matter what ECC-based reads
+ * return).
+ *
+ * 4) "Raw" read operations return a direct view of the physical bytes in the

+ *    page, using the conventional definition of which bytes are data and which
+ *    are OOB. This gives the caller a way to see the actual, physical bytes
+ *    in the page, without the distortions applied by our ECC engine.

 tools/Makefile  |    6 +
 tools/mxsboot.c |  687
+++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed,
693 insertions(+), 0 deletions(-)
 create mode 100644 tools/mxsboot.c

Quoted 7 lines · On Monday, September 12, 2011 00:06:45 Marek Vasut wrote:

 tools/Makefile  |    6 +
 tools/mxsboot.c |  687

+++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 693 insertions(+), 0 deletions(-)

 create mode 100644 tools/mxsboot.c

missing .gitignore update

Quoted 4 lines

tools/mxsboot.c new file +0 -0

tools/mxsboot.c line 34

Quoted 9 lines

tools/mxsboot.c new file +9 -0

+#include <fcntl.h>
+#include <malloc.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>

drop the malloc.h and probably add compiler.h
-mike

Quoted 4 lines · Mike Frysinger

Quoted 3 lines · On Monday, September 12, 2011 00:06:45 Marek Vasut wrote:

 tools/Makefile  |    6 +
 tools/mxsboot.c |  687

Quoted 6 lines

Quoted 4 lines

+++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 693 insertions(+), 0 deletions(-)

 create mode 100644 tools/mxsboot.c

missing .gitignore update

Ignore what?

Quoted 8 lines · On Monday, September 12, 2011 13:40:35 Marek Vasut wrote:

Quoted 7 lines · Mike Frysinger

Quoted 6 lines · On Monday, September 12, 2011 00:06:45 Marek Vasut wrote:

 tools/Makefile  |    6 +
 tools/mxsboot.c |  687

+++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 693 insertions(+), 0 deletions(-)

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

 create mode 100644 tools/mxsboot.c

missing .gitignore update

Ignore what?

the "mxsboot" tool of course
-mike

Quoted 6 lines · On Monday, September 12, 2011 00:06:46 Marek Vasut wrote:

 Makefile |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

Makefile +0 -0

Makefile $(obj)u-boot.ubl: $(obj)u-boot-nand.bin · line 403

Quoted 3 lines

+$(obj)u-boot.sb: $(obj)u-boot.bin $(obj)spl/u-boot-spl.bin

Makefile +2 -0

+		elftosb -zdf imx28 -c board/denx/m28evk/u-boot.bd \
+			-o $(obj)u-boot.sb

generated files should probably be in .gitignore too -mike