Skip to contentSkip to conversation

mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

RFC PATCH Superseded Simon Horman 2 participants 14 messages Mar 14, 2011 – Mar 24, 2011

Subsystems (7)
Documentation Arm (32-bit) Arm sub-architectures MMC, SD and SDIO +3 more subsystems

v3 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

Simon Horman

author
#0 lore raw

v3 cover mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

The first three patches shuffle some code around.
The fourth patch has the new boot code and the bulk of the code.

 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt       |   43 +
 arch/arm/Kconfig                                     |   35 -
 arch/arm/boot/compressed/Makefile                    |    9 
 arch/arm/boot/compressed/head-shmobile.S             |   12 
 arch/arm/boot/compressed/mmcif-sh7372.c              |   14 
 arch/arm/boot/compressed/sdhi-shmobile.c             |  501 ++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h      |   29 +
 arch/arm/mach-shmobile/include/mach/mmc-mackerel.h   |   38 +
 arch/arm/mach-shmobile/include/mach/mmc.h            |   18 
 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h    |   29 -
 arch/arm/mach-shmobile/include/mach/mmcif-mackerel.h |   39 -
 arch/arm/mach-shmobile/include/mach/mmcif.h          |   18 
 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h    |   58 ++
 arch/arm/mach-shmobile/include/mach/sdhi.h           |   16 
 arch/sh/boot/romimage/mmcif-sh7724.c                 |   10 
 drivers/mmc/host/tmio_mmc.c                          |   46 -
 include/linux/mmc/boot.h                             |    7 
 include/linux/mmc/sh_mmcif.h                         |    3 
 include/linux/mmc/tmio.h                             |   49 +
 19 files changed, 812 insertions(+), 162 deletions(-)
author
#1 lore raw

PATCH v3 1/4 mmc: tmio_mmc: Move some defines into a shared header

Also add TMIO_BBS.

This allows these defines to also be used by zboot.

Cc Guennadi Liakhovetski <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This almost certainly conflicts with recent work by Guennadi. Though it should be trivial for either of us to rebase our patches.

---
 drivers/mmc/host/tmio_mmc.c |   46 +--------------------------------------
 include/linux/mmc/tmio.h    |   49 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 51 insertions(+), 44 deletions(-)
 create mode 100644 include/linux/mmc/tmio.h
drivers/mmc/host/tmio_mmc.c +2 -44
index e3c6ef2..c1a81f8 100644
@@ -36,55 +36,13 @@
 #include <linux/mfd/core.h>
 #include <linux/mfd/tmio.h>
 #include <linux/mmc/host.h>
+#include <linux/mmc/tmio.h>
 #include <linux/module.h>
 #include <linux/pagemap.h>
 #include <linux/scatterlist.h>
 #include <linux/workqueue.h>
 #include <linux/spinlock.h>
 
-#define CTL_SD_CMD 0x00
-#define CTL_ARG_REG 0x04
-#define CTL_STOP_INTERNAL_ACTION 0x08
-#define CTL_XFER_BLK_COUNT 0xa
-#define CTL_RESPONSE 0x0c
-#define CTL_STATUS 0x1c
-#define CTL_IRQ_MASK 0x20
-#define CTL_SD_CARD_CLK_CTL 0x24
-#define CTL_SD_XFER_LEN 0x26
-#define CTL_SD_MEM_CARD_OPT 0x28
-#define CTL_SD_ERROR_DETAIL_STATUS 0x2c
-#define CTL_SD_DATA_PORT 0x30
-#define CTL_TRANSACTION_CTL 0x34
-#define CTL_SDIO_STATUS 0x36
-#define CTL_SDIO_IRQ_MASK 0x38
-#define CTL_RESET_SD 0xe0
-#define CTL_SDIO_REGS 0x100
-#define CTL_CLK_AND_WAIT_CTL 0x138
-#define CTL_RESET_SDIO 0x1e0
-
-/* Definitions for values the CTRL_STATUS register can take. */
-#define TMIO_STAT_CMDRESPEND    0x00000001
-#define TMIO_STAT_DATAEND       0x00000004
-#define TMIO_STAT_CARD_REMOVE   0x00000008
-#define TMIO_STAT_CARD_INSERT   0x00000010
-#define TMIO_STAT_SIGSTATE      0x00000020
-#define TMIO_STAT_WRPROTECT     0x00000080
-#define TMIO_STAT_CARD_REMOVE_A 0x00000100
-#define TMIO_STAT_CARD_INSERT_A 0x00000200
-#define TMIO_STAT_SIGSTATE_A    0x00000400
-#define TMIO_STAT_CMD_IDX_ERR   0x00010000
-#define TMIO_STAT_CRCFAIL       0x00020000
-#define TMIO_STAT_STOPBIT_ERR   0x00040000
-#define TMIO_STAT_DATATIMEOUT   0x00080000
-#define TMIO_STAT_RXOVERFLOW    0x00100000
-#define TMIO_STAT_TXUNDERRUN    0x00200000
-#define TMIO_STAT_CMDTIMEOUT    0x00400000
-#define TMIO_STAT_RXRDY         0x01000000
-#define TMIO_STAT_TXRQ          0x02000000
-#define TMIO_STAT_ILL_FUNC      0x20000000
-#define TMIO_STAT_CMD_BUSY      0x40000000
-#define TMIO_STAT_ILL_ACCESS    0x80000000
-
 /* Definitions for values the CTRL_SDIO_STATUS register can take. */
 #define TMIO_SDIO_STAT_IOIRQ	0x0001
 #define TMIO_SDIO_STAT_EXPUB52	0x4000

@@ -1290,7 +1248,7 @@ static int __devinit tmio_mmc_probe(struct platform_device *dev)
 	mmc->f_max = pdata->hclk;
 	mmc->f_min = mmc->f_max / 512;
 	mmc->max_segs = 32;
-	mmc->max_blk_size = 512;
+	mmc->max_blk_size = TMIO_BBS;
 	mmc->max_blk_count = (PAGE_CACHE_SIZE / mmc->max_blk_size) *
 		mmc->max_segs;
 	mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
include/linux/mmc/tmio.h new file +49 -0

49 lines not on this page · raw message

Signature · 1 line
1.7.2.3
author
#2 lore raw

PATCH v3 2/4 mmc, ARM: Rename SuperH Mobile ARM zboot helpers

In reply to Simon Horman

These headers and helpers will also be used for SDHI boot so the mmcif name will start to make a lot less sense.

Signed-off-by Simon Horman <[email protected]>
---
 arch/arm/boot/compressed/mmcif-sh7372.c            |   12 +++---
 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h    |   29 +++++++++++++++
 arch/arm/mach-shmobile/include/mach/mmc-mackerel.h |   38 +++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/mmc.h          |   18 +++++++++
 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h  |   29 ---------------
 .../mach-shmobile/include/mach/mmcif-mackerel.h    |   39 --------------------
 arch/arm/mach-shmobile/include/mach/mmcif.h        |   18 ---------
 7 files changed, 91 insertions(+), 92 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/mmc-mackerel.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/mmc.h
 delete mode 100644 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
 delete mode 100644 arch/arm/mach-shmobile/include/mach/mmcif-mackerel.h
 delete mode 100644 arch/arm/mach-shmobile/include/mach/mmcif.h
arch/arm/boot/compressed/mmcif-sh7372.c +6 -6
index e6180af..28bcf3c 100644
@@ -10,7 +10,7 @@
  */
 
 #include <linux/mmc/sh_mmcif.h>
-#include <mach/mmcif.h>
+#include <mach/mmc.h>
 
 #define MMCIF_BASE      (void __iomem *)0xe6bd0000
 

@@ -41,8 +41,8 @@
  */
 asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 {
-	mmcif_init_progress();
-	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+	mmc_init_progress();
+	mmc_update_progress(MMCIF_PROGRESS_ENTER);
 
 	/* Initialise MMC
 	 * registers: PORT84CR-PORT92CR

@@ -68,12 +68,12 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 	/* Enable clock to MMC hardware block */
 	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
 
-	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+	mmc_update_progress(MMCIF_PROGRESS_INIT);
 
 	/* setup MMCIF hardware */
 	sh_mmcif_boot_init(MMCIF_BASE);
 
-	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+	mmc_update_progress(MMCIF_PROGRESS_LOAD);
 
 	/* load kernel via MMCIF interface */
 	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is@block 2 */

@@ -83,5 +83,5 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 	/* Disable clock to MMC hardware block */
 	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
 
-	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+	mmc_update_progress(MMCIF_PROGRESS_DONE);
 }
arch/arm/mach-shmobile/include/mach/mmc-ap4eb.h new file +29 -0
new file mode 100644
index 0000000..db59fdb
@@ -0,0 +1,29 @@
+#ifndef MMC_AP4EB_H
+#define MMC_AP4EB_H
+
+#define PORT185CR      (void __iomem *)0xe60520b9
+#define PORT186CR      (void __iomem *)0xe60520ba
+#define PORT187CR      (void __iomem *)0xe60520bb
+#define PORT188CR      (void __iomem *)0xe60520bc
+
+#define PORTR191_160DR (void __iomem *)0xe6056014
+
+static inline void mmc_init_progress(void)
+{
+       /* Initialise LEDS1-4
+        * registers: PORT185CR-PORT188CR (LED1-LED4 Control)
+        * value:     0x10 - enable output
+        */
+       __raw_writeb(0x10, PORT185CR);
+       __raw_writeb(0x10, PORT186CR);
+       __raw_writeb(0x10, PORT187CR);
+       __raw_writeb(0x10, PORT188CR);
+}
+
+static inline void mmc_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMC_AP4EB_H */
arch/arm/mach-shmobile/include/mach/mmc-mackerel.h new file +38 -0
new file mode 100644
index 0000000..15d3a9e
@@ -0,0 +1,38 @@
+#ifndef MMC_MACKEREL_H
+#define MMC_MACKEREL_H
+
+#define PORT0CR      (void __iomem *)0xe6051000
+#define PORT1CR      (void __iomem *)0xe6051001
+#define PORT2CR      (void __iomem *)0xe6051002
+#define PORT159CR    (void __iomem *)0xe605009f
+
+#define PORTR031_000DR (void __iomem *)0xe6055000
+#define PORTL159_128DR (void __iomem *)0xe6054010
+
+static inline void mmc_init_progress(void)
+{
+       /* Initialise LEDS0-3
+        * registers: PORT0CR-PORT2CR,PORT159CR (LED0-LED3 Control)
+        * value:     0x10 - enable output
+        */
+       __raw_writeb(0x10, PORT0CR);
+       __raw_writeb(0x10, PORT1CR);
+       __raw_writeb(0x10, PORT2CR);
+       __raw_writeb(0x10, PORT159CR);
+}
+
+static inline void mmc_update_progress(int n)
+{
+	unsigned a = 0, b = 0;
+
+	if (n < 3)
+		a = 1 << n;
+	else
+		b = 1 << 31;
+
+	__raw_writel((__raw_readl(PORTR031_000DR) & ~0x7) | a,
+		     PORTR031_000DR);
+	__raw_writel((__raw_readl(PORTL159_128DR) & ~(1 << 31)) | b,
+		     PORTL159_128DR);
+}
+#endif /* MMC_MACKEREL_H */
arch/arm/mach-shmobile/include/mach/mmc.h new file +18 -0
new file mode 100644
index 0000000..e11560a
@@ -0,0 +1,18 @@
+#ifndef MMC_H
+#define MMC_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmc-ap4eb.h"
+#elif CONFIG_MACH_MACKEREL
+#include "mach/mmc-mackerel.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMC_H */
arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h deleted +0 -29
deleted file mode 100644
index a8d02be..0000000
@@ -1,29 +0,0 @@
-#ifndef MMCIF_AP4EB_H
-#define MMCIF_AP4EB_H
-
-#define PORT185CR      (void __iomem *)0xe60520b9
-#define PORT186CR      (void __iomem *)0xe60520ba
-#define PORT187CR      (void __iomem *)0xe60520bb
-#define PORT188CR      (void __iomem *)0xe60520bc
-
-#define PORTR191_160DR (void __iomem *)0xe6056014
-
-static inline void mmcif_init_progress(void)
-{
-       /* Initialise LEDS1-4
-        * registers: PORT185CR-PORT188CR (LED1-LED4 Control)
-        * value:     0x10 - enable output
-        */
-       __raw_writeb(0x10, PORT185CR);
-       __raw_writeb(0x10, PORT186CR);
-       __raw_writeb(0x10, PORT187CR);
-       __raw_writeb(0x10, PORT188CR);
-}
-
-static inline void mmcif_update_progress(int n)
-{
-	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
-		     (1 << (25 + n)), PORTR191_160DR);
-}
-
-#endif /* MMCIF_AP4EB_H */
arch/arm/mach-shmobile/include/mach/mmcif-mackerel.h deleted +0 -39
deleted file mode 100644
index 4b4f694..0000000
@@ -1,39 +0,0 @@
-#ifndef MMCIF_MACKEREL_H
-#define MMCIF_MACKEREL_H
-
-#define PORT0CR      (void __iomem *)0xe6051000
-#define PORT1CR      (void __iomem *)0xe6051001
-#define PORT2CR      (void __iomem *)0xe6051002
-#define PORT159CR    (void __iomem *)0xe605009f
-
-#define PORTR031_000DR (void __iomem *)0xe6055000
-#define PORTL159_128DR (void __iomem *)0xe6054010
-
-static inline void mmcif_init_progress(void)
-{
-       /* Initialise LEDS0-3
-        * registers: PORT0CR-PORT2CR,PORT159CR (LED0-LED3 Control)
-        * value:     0x10 - enable output
-        */
-       __raw_writeb(0x10, PORT0CR);
-       __raw_writeb(0x10, PORT1CR);
-       __raw_writeb(0x10, PORT2CR);
-       __raw_writeb(0x10, PORT159CR);
-}
-
-static inline void mmcif_update_progress(int n)
-{
-	unsigned a = 0, b = 0;
-
-	if (n < 3)
-		a = 1 << n;
-	else
-		b = 1 << 31;
-
-	__raw_writel((__raw_readl(PORTR031_000DR) & ~0x7) | a,
-		     PORTR031_000DR);
-	__raw_writel((__raw_readl(PORTL159_128DR) & ~(1 << 31)) | b,
-		     PORTL159_128DR);
-}
-
-#endif /* MMCIF_MACKEREL_H */
arch/arm/mach-shmobile/include/mach/mmcif.h deleted +0 -18
deleted file mode 100644
index f4dc327..0000000
@@ -1,18 +0,0 @@
-#ifndef MMCIF_H
-#define MMCIF_H
-
-/**************************************************
- *
- *		board specific settings
- *
- **************************************************/
-
-#ifdef CONFIG_MACH_AP4EVB
-#include "mach/mmcif-ap4eb.h"
-#elif CONFIG_MACH_MACKEREL
-#include "mach/mmcif-mackerel.h"
-#else
-#error "unsupported board."
-#endif
-
-#endif /* MMCIF_H */
Signature · 1 line
1.7.2.3
author
#3 lore raw

PATCH v3 3/4 mmc: Add MMC_PROGRESS_*

In reply to Simon Horman

This is my second attempt to make this enum generally available. The first attempt added MMCIF_PROGRESS_* to include/linux/mmc/sh_mmcif.h. However this is not sufficiently generic as the enum will be used by SDHI boot code.

Signed-off-by Simon Horman <[email protected]>
---
 arch/arm/boot/compressed/mmcif-sh7372.c |    8 ++++----
 arch/sh/boot/romimage/mmcif-sh7724.c    |    8 ++++----
 include/linux/mmc/boot.h                |    7 +++++++
 include/linux/mmc/sh_mmcif.h            |    3 ---
 4 files changed, 15 insertions(+), 11 deletions(-)
 create mode 100644 include/linux/mmc/boot.h
arch/arm/boot/compressed/mmcif-sh7372.c +4 -4
index 28bcf3c..86b26a1 100644
@@ -42,7 +42,7 @@
 asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 {
 	mmc_init_progress();
-	mmc_update_progress(MMCIF_PROGRESS_ENTER);
+	mmc_update_progress(MMC_PROGRESS_ENTER);
 
 	/* Initialise MMC
 	 * registers: PORT84CR-PORT92CR

@@ -68,12 +68,12 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 	/* Enable clock to MMC hardware block */
 	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
 
-	mmc_update_progress(MMCIF_PROGRESS_INIT);
+	mmc_update_progress(MMC_PROGRESS_INIT);
 
 	/* setup MMCIF hardware */
 	sh_mmcif_boot_init(MMCIF_BASE);
 
-	mmc_update_progress(MMCIF_PROGRESS_LOAD);
+	mmc_update_progress(MMC_PROGRESS_LOAD);
 
 	/* load kernel via MMCIF interface */
 	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is@block 2 */

@@ -83,5 +83,5 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
 	/* Disable clock to MMC hardware block */
 	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
 
-	mmc_update_progress(MMCIF_PROGRESS_DONE);
+	mmc_update_progress(MMC_PROGRESS_DONE);
 }
arch/sh/boot/romimage/mmcif-sh7724.c +4 -4
index c84e783..1d13335 100644
@@ -29,7 +29,7 @@
  */
 asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
 {
-	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+	mmcif_update_progress(MMC_PROGRESS_ENTER);
 
 	/* enable clock to the MMCIF hardware block */
 	__raw_writel(__raw_readl(MSTPCR2) & ~0x20000000, MSTPCR2);

@@ -52,12 +52,12 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
 	/* high drive capability for MMC pins */
 	__raw_writew(__raw_readw(DRVCRA) | 0x3000, DRVCRA);
 
-	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+	mmcif_update_progress(MMC_PROGRESS_INIT);
 
 	/* setup MMCIF hardware */
 	sh_mmcif_boot_init(MMCIF_BASE);
 
-	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+	mmcif_update_progress(MMC_PROGRESS_LOAD);
 
 	/* load kernel via MMCIF interface */
 	sh_mmcif_boot_do_read(MMCIF_BASE, 512,

@@ -67,5 +67,5 @@ asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
 	/* disable clock to the MMCIF hardware block */
 	__raw_writel(__raw_readl(MSTPCR2) | 0x20000000, MSTPCR2);
 
-	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+	mmcif_update_progress(MMC_PROGRESS_DONE);
 }
include/linux/mmc/boot.h new file +7 -0
new file mode 100644
index 0000000..39d787c
@@ -0,0 +1,7 @@
+#ifndef MMC_BOOT_H
+#define MMC_BOOT_H
+
+enum { MMC_PROGRESS_ENTER, MMC_PROGRESS_INIT,
+       MMC_PROGRESS_LOAD, MMC_PROGRESS_DONE };
+
+#endif
include/linux/mmc/sh_mmcif.h +0 -3
index 38d3930..9eb9b4b 100644
@@ -104,9 +104,6 @@ static inline void sh_mmcif_writel(void __iomem *addr, int reg, u32 val)
 
 #define SH_MMCIF_BBS 512 /* boot block size */
 
-enum { MMCIF_PROGRESS_ENTER, MMCIF_PROGRESS_INIT,
-       MMCIF_PROGRESS_LOAD, MMCIF_PROGRESS_DONE };
-
 static inline void sh_mmcif_boot_cmd_send(void __iomem *base,
 					  unsigned long cmd, unsigned long arg)
 {
Signature · 1 line
1.7.2.3
author
#4 lore raw

PATCH v3 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

In reply to Simon Horman

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
+ Include linux/io.h

---
 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt    |   43 ++
 arch/arm/Kconfig                                  |   35 ++-
 arch/arm/boot/compressed/Makefile                 |    9 +-
 arch/arm/boot/compressed/head-shmobile.S          |   12 +-
 arch/arm/boot/compressed/mmcif-sh7372.c           |    2 +-
 arch/arm/boot/compressed/sdhi-shmobile.c          |  501 +++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h |   58 +++
 arch/arm/mach-shmobile/include/mach/sdhi.h        |   16 +
 arch/sh/boot/romimage/mmcif-sh7724.c              |    2 +-
 9 files changed, 659 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi.h
Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt new file +43 -0
new file mode 100644
index 0000000..dbd21ef
@@ -0,0 +1,43 @@
+ROM-able zImage boot from eSD
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and
+SuperH Mobile ARM will to boot directly from the SDHI hardware block.
+
+This is achieved by the mask ROM loading the first portion of the image into
+MERAM and then jumping to it. This portion contains loader code which
+copies the entire image to SDRAM and jumps to it. From there the zImage
+boot code proceeds as normal, uncompressing the image into its final
+location and then jumping to it.
+
+This code has been tested on an mackerel board using the developer 1A eSD
+boot mode which is configured using the following jumper settings.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x| |x|x|
+S4 -+-+-+-+-+-+-+-
+    | | | |x| | |x on
+
+The eSD card needs to be present in SDHI slot 1 (CN7).
+As such S1 and S33 also need to be configured as per
+the notes in arch/arm/mach-shmobile/board-mackerel.c.
+
+A partial zImage must be written to physical partition #1 (boot)
+of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to
+accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 count=9
+
+A full copy of _the same_ zImage should be written to physical partition #1
+(boot) of the eSD@sector 0. This should _not_ be in vrl4 format.
+
+	vrl4 < zImage | dd of=/dev/sdX bs=512
+
+Note: The commands above assume that the physical partition has been
+switched. No such facility currently exists in the Linux Kernel.
+
+Physical partitions are described in the eSD specification.  At the time of
+writing they are not the same as partitions that are typically configured
+using fdisk and visible through /proc/partitions
+
arch/arm/Kconfig +26 -9
index 574ce60..55892eb 100644
@@ -1685,17 +1685,34 @@ config ZBOOT_ROM
 	  Say Y here if you intend to execute your compressed kernel image
 	  (zImage) directly from ROM or flash.  If unsure, say N.
 
+choice
+	prompt "Include SD/MMC loader in zImage (EXPERIMENTAL)"
+	depends on ZBOOT_ROM && ARCH_SHMOBILE && EXPERIMENTAL
+	default ZBOOT_ROM_NONE
+	help
+	  Include experimental SD/MMC loading code in the ROM-able zImage.
+	  With this enabled it is possible to write the the ROM-able zImage
+	  kernel image to an MMC or SD card and boot the kernel straight
+	  from the reset vector. At reset the processor Mask ROM will load
+	  the first part of the the ROM-able zImage which in turn loads the
+	  rest the kernel image to RAM.
+
+config ZBOOT_ROM_NONE
+	bool "No SD/MMC loader in zImage (EXPERIMENTAL)"
+	help
+	  Do not load image from SD or MMC
+
 config ZBOOT_ROM_MMCIF
 	bool "Include MMCIF loader in zImage (EXPERIMENTAL)"
-	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
-	help
-	  Say Y here to include experimental MMCIF loading code in the
-	  ROM-able zImage. With this enabled it is possible to write the
-	  the ROM-able zImage kernel image to an MMC card and boot the
-	  kernel straight from the reset vector. At reset the processor
-	  Mask ROM will load the first part of the the ROM-able zImage
-	  which in turn loads the rest the kernel image to RAM using the
-	  MMCIF hardware block.
+	help
+	  Load image from MMCIF hardware block.
+
+config ZBOOT_ROM_SH_MOBILE_SDHI
+	bool "Include SuperH Mobile SDHI loader in zImage (EXPERIMENTAL)"
+	help
+	  Load image from SDHI hardware block
+
+endchoice
 
 config CMDLINE
 	string "Default kernel command string"
arch/arm/boot/compressed/Makefile +7 -2
index f9f77c6..60bd76d 100644
@@ -6,13 +6,18 @@
 
 OBJS		=
 
-# Ensure that mmcif loader code appears early in the image
+# Ensure that MMCIF loader code appears early in the image
 # to minimise that number of bocks that have to be read in
 # order to load it.
 ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
-ifeq ($(CONFIG_ARCH_SH7372),y)
 OBJS		+= mmcif-sh7372.o
 endif
+
+# Ensure that SDHI loader code appears early in the image
+# to minimise that number of bocks that have to be read in
+# order to load it.
+ifeq ($(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI),y)
+OBJS		+= sdhi-shmobile.o
 endif
 
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
arch/arm/boot/compressed/head-shmobile.S +6 -6
index c943d2e..fe3719b 100644
@@ -25,14 +25,14 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-#ifdef CONFIG_ZBOOT_ROM_MMCIF
-	/* Load image from MMC */
-	adr	sp, __tmp_stack + 128
+#if defined(CONFIG_ZBOOT_ROM_MMCIF) || defined(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI)
+	/* Load image from MMC/SD */
+	adr	sp, __tmp_stack + 256
 	ldr	r0, __image_start
 	ldr	r1, __image_end
 	subs	r1, r1, r0
 	ldr	r0, __load_base
-	bl	mmcif_loader
+	bl	mmc_loader
 
 	/* Jump to loaded code */
 	ldr	r0, __loaded

@@ -51,9 +51,9 @@ __loaded:
 	.long	__continue
 	.align
 __tmp_stack:
-	.space	128
+	.space	256
 __continue:
-#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+#endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
 	b	1f
 __atags:@ tag #1
arch/arm/boot/compressed/mmcif-sh7372.c +1 -1
index 86b26a1..08fc0f3 100644
@@ -39,7 +39,7 @@
  * to an MMC card
  * # dd if=vrl4.out of=/dev/sdx bs=512 seek=1
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long len)
 {
 	mmc_init_progress();
 	mmc_update_progress(MMC_PROGRESS_ENTER);
arch/arm/boot/compressed/sdhi-shmobile.c new file +501 -0

501 lines not on this page · raw message

arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h new file +58 -0

58 lines not on this page · raw message

arch/arm/mach-shmobile/include/mach/sdhi.h new file +16 -0
new file mode 100644
index 0000000..0ec9e69
@@ -0,0 +1,16 @@
+#ifndef SDHI_H
+#define SDHI_H
+
+/**************************************************
+ *
+ *		CPU specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_ARCH_SH7372
+#include "mach/sdhi-sh7372.h"
+#else
+#error "unsupported CPU."
+#endif
+
+#endif /* SDHI_H */
arch/sh/boot/romimage/mmcif-sh7724.c +1 -1
index 1d13335..17c4ed3 100644
@@ -27,7 +27,7 @@
  * use the following line to write the romImage to an MMC card
  * # dd if=arch/sh/boot/romImage of=/dev/sdx bs=512 seek=512
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long no_bytes)
 {
 	mmcif_update_progress(MMC_PROGRESS_ENTER);
Signature · 1 line
1.7.2.3
author
#5 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. Thanks to Magnus Damm.

---
 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt    |   43 ++
 arch/arm/Kconfig                                  |   35 ++-
 arch/arm/boot/compressed/Makefile                 |    9 +-
 arch/arm/boot/compressed/head-shmobile.S          |   12 +-
 arch/arm/boot/compressed/mmcif-sh7372.c           |    2 +-
 arch/arm/boot/compressed/sdhi-shmobile.c          |  498 +++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h |   61 +++
 arch/arm/mach-shmobile/include/mach/sdhi.h        |   16 +
 arch/sh/boot/romimage/mmcif-sh7724.c              |    2 +-
 9 files changed, 659 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.c
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi.h
Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt new file +43 -0
new file mode 100644
index 0000000..dbd21ef
@@ -0,0 +1,43 @@
+ROM-able zImage boot from eSD
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and
+SuperH Mobile ARM will to boot directly from the SDHI hardware block.
+
+This is achieved by the mask ROM loading the first portion of the image into
+MERAM and then jumping to it. This portion contains loader code which
+copies the entire image to SDRAM and jumps to it. From there the zImage
+boot code proceeds as normal, uncompressing the image into its final
+location and then jumping to it.
+
+This code has been tested on an mackerel board using the developer 1A eSD
+boot mode which is configured using the following jumper settings.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x| |x|x|
+S4 -+-+-+-+-+-+-+-
+    | | | |x| | |x on
+
+The eSD card needs to be present in SDHI slot 1 (CN7).
+As such S1 and S33 also need to be configured as per
+the notes in arch/arm/mach-shmobile/board-mackerel.c.
+
+A partial zImage must be written to physical partition #1 (boot)
+of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to
+accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 count=9
+
+A full copy of _the same_ zImage should be written to physical partition #1
+(boot) of the eSD@sector 0. This should _not_ be in vrl4 format.
+
+	vrl4 < zImage | dd of=/dev/sdX bs=512
+
+Note: The commands above assume that the physical partition has been
+switched. No such facility currently exists in the Linux Kernel.
+
+Physical partitions are described in the eSD specification.  At the time of
+writing they are not the same as partitions that are typically configured
+using fdisk and visible through /proc/partitions
+
arch/arm/Kconfig +26 -9
index 574ce60..55892eb 100644
@@ -1685,17 +1685,34 @@ config ZBOOT_ROM
 	  Say Y here if you intend to execute your compressed kernel image
 	  (zImage) directly from ROM or flash.  If unsure, say N.
 
+choice
+	prompt "Include SD/MMC loader in zImage (EXPERIMENTAL)"
+	depends on ZBOOT_ROM && ARCH_SHMOBILE && EXPERIMENTAL
+	default ZBOOT_ROM_NONE
+	help
+	  Include experimental SD/MMC loading code in the ROM-able zImage.
+	  With this enabled it is possible to write the the ROM-able zImage
+	  kernel image to an MMC or SD card and boot the kernel straight
+	  from the reset vector. At reset the processor Mask ROM will load
+	  the first part of the the ROM-able zImage which in turn loads the
+	  rest the kernel image to RAM.
+
+config ZBOOT_ROM_NONE
+	bool "No SD/MMC loader in zImage (EXPERIMENTAL)"
+	help
+	  Do not load image from SD or MMC
+
 config ZBOOT_ROM_MMCIF
 	bool "Include MMCIF loader in zImage (EXPERIMENTAL)"
-	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
-	help
-	  Say Y here to include experimental MMCIF loading code in the
-	  ROM-able zImage. With this enabled it is possible to write the
-	  the ROM-able zImage kernel image to an MMC card and boot the
-	  kernel straight from the reset vector. At reset the processor
-	  Mask ROM will load the first part of the the ROM-able zImage
-	  which in turn loads the rest the kernel image to RAM using the
-	  MMCIF hardware block.
+	help
+	  Load image from MMCIF hardware block.
+
+config ZBOOT_ROM_SH_MOBILE_SDHI
+	bool "Include SuperH Mobile SDHI loader in zImage (EXPERIMENTAL)"
+	help
+	  Load image from SDHI hardware block
+
+endchoice
 
 config CMDLINE
 	string "Default kernel command string"
arch/arm/boot/compressed/Makefile +7 -2
index f9f77c6..60bd76d 100644
@@ -6,13 +6,18 @@
 
 OBJS		=
 
-# Ensure that mmcif loader code appears early in the image
+# Ensure that MMCIF loader code appears early in the image
 # to minimise that number of bocks that have to be read in
 # order to load it.
 ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
-ifeq ($(CONFIG_ARCH_SH7372),y)
 OBJS		+= mmcif-sh7372.o
 endif
+
+# Ensure that SDHI loader code appears early in the image
+# to minimise that number of bocks that have to be read in
+# order to load it.
+ifeq ($(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI),y)
+OBJS		+= sdhi-shmobile.o
 endif
 
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
arch/arm/boot/compressed/head-shmobile.S +6 -6
index c943d2e..fe3719b 100644
@@ -25,14 +25,14 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-#ifdef CONFIG_ZBOOT_ROM_MMCIF
-	/* Load image from MMC */
-	adr	sp, __tmp_stack + 128
+#if defined(CONFIG_ZBOOT_ROM_MMCIF) || defined(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI)
+	/* Load image from MMC/SD */
+	adr	sp, __tmp_stack + 256
 	ldr	r0, __image_start
 	ldr	r1, __image_end
 	subs	r1, r1, r0
 	ldr	r0, __load_base
-	bl	mmcif_loader
+	bl	mmc_loader
 
 	/* Jump to loaded code */
 	ldr	r0, __loaded

@@ -51,9 +51,9 @@ __loaded:
 	.long	__continue
 	.align
 __tmp_stack:
-	.space	128
+	.space	256
 __continue:
-#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+#endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
 	b	1f
 __atags:@ tag #1
arch/arm/boot/compressed/mmcif-sh7372.c +1 -1
index 86b26a1..08fc0f3 100644
@@ -39,7 +39,7 @@
  * to an MMC card
  * # dd if=vrl4.out of=/dev/sdx bs=512 seek=1
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long len)
 {
 	mmc_init_progress();
 	mmc_update_progress(MMC_PROGRESS_ENTER);
arch/arm/boot/compressed/sdhi-shmobile.c new file +498 -0

498 lines not on this page · raw message

arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h new file +61 -0

61 lines not on this page · raw message

arch/arm/mach-shmobile/include/mach/sdhi.h new file +16 -0
new file mode 100644
index 0000000..0ec9e69
@@ -0,0 +1,16 @@
+#ifndef SDHI_H
+#define SDHI_H
+
+/**************************************************
+ *
+ *		CPU specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_ARCH_SH7372
+#include "mach/sdhi-sh7372.h"
+#else
+#error "unsupported CPU."
+#endif
+
+#endif /* SDHI_H */
arch/sh/boot/romimage/mmcif-sh7724.c +1 -1
index 1d13335..17c4ed3 100644
@@ -27,7 +27,7 @@
  * use the following line to write the romImage to an MMC card
  * # dd if=arch/sh/boot/romImage of=/dev/sdx bs=512 seek=512
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long no_bytes)
 {
 	mmcif_update_progress(MMC_PROGRESS_ENTER);
Signature · 1 line
1.7.2.3
maintainer
#6 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Hi Simon,

Thanks for your work on this!

Quoted 60 lines · Simon Horman

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. ?This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
?As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
?+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
?+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. ?Thanks to Magnus Damm.
---

(quoted diff) +22 -0
+asmlinkage void mmc_loader(unsigned short *buf, unsigned long len)
+{
+ ? ? ? int high_capacity;
+
+ ? ? ? mmc_init_progress();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_ENTER);
+ ? ? ? sdhi_boot_enter();
+
+ ? ? ? /* setup SDHI hardware */
+ ? ? ? mmc_update_progress(MMC_PROGRESS_INIT);
+ ? ? ? high_capacity = sdhi_boot_init(SDHI_BASE);
+ ? ? ? if (high_capacity < 0)
+ ? ? ? ? ? ? ? goto err;
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_LOAD);
+ ? ? ? /* load kernel */
+ ? ? ? if (sdhi_boot_do_read(SDHI_BASE, high_capacity,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0, /* Kernel is at block 1 */
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? (len + TMIO_BBS - 1) / TMIO_BBS, buf))
+ ? ? ? ? ? ? ? goto err;
+

Review

Quoted 10 lines
(quoted diff) +10 -0
+ ? ? ? sdhi_boot_cleanup();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_DONE);
+
+ ? ? ? return;
+err:
+ ? ? ? __raw_writel(__raw_readl(PORTR031_000DR) | 1, PORTR031_000DR);
+ ? ? ? for(;;);
+
+}

Sorry for not catching this earlier, but this __raw_writel() to PORTR031_000DR is cpu specific as well. So please move that to the CPU specific code.

Not sure if it makes sense at this point, but perhaps it's a good idea to move the mmc_loader() function into the CPU specific portion. As you know, the CPU itself has multiple SDHI hardware blocks, and because of that we want the common SDHI loader to be written to support any SDHI hardware block instance.

Right now the SDHI_BASE variable is limiting the shared SDHI loader code to a fixed hardware block instance. That's fine because we only boot from a single SDHI hardware block instance on sh7372, but future processors most likely support selecting boot SDHI hardware block instance.

Apart from those minor bits I think the code is getting into a really good shape!

Thanks,

/ magnus

author
#7 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Hi Magnus,

Quoted 3 lines · Magnus Damm

Hi Simon,

Thanks for your work on this!

[ snip ]

Quoted 68 lines · Simon Horman
Quoted 66 lines

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. ?This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
?As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
?+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
?+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. ?Thanks to Magnus Damm.
---

(quoted diff) +28 -0
+asmlinkage void mmc_loader(unsigned short *buf, unsigned long len)
+{
+ ? ? ? int high_capacity;
+
+ ? ? ? mmc_init_progress();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_ENTER);
+ ? ? ? sdhi_boot_enter();
+
+ ? ? ? /* setup SDHI hardware */
+ ? ? ? mmc_update_progress(MMC_PROGRESS_INIT);
+ ? ? ? high_capacity = sdhi_boot_init(SDHI_BASE);
+ ? ? ? if (high_capacity < 0)
+ ? ? ? ? ? ? ? goto err;
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_LOAD);
+ ? ? ? /* load kernel */
+ ? ? ? if (sdhi_boot_do_read(SDHI_BASE, high_capacity,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0, /* Kernel is at block 1 */
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? (len + TMIO_BBS - 1) / TMIO_BBS, buf))
+ ? ? ? ? ? ? ? goto err;
+
+ ? ? ? sdhi_boot_cleanup();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_DONE);
+
+ ? ? ? return;
+err:
Quoted 8 lines

Review

Quoted 4 lines

+ ? ? ? __raw_writel(__raw_readl(PORTR031_000DR) | 1, PORTR031_000DR);
+ ? ? ? for(;;);

(quoted diff) +2 -0
+
+}

Sorry for not catching this earlier, but this __raw_writel() to PORTR031_000DR is cpu specific as well. So please move that to the CPU specific code.

I will just remove that code, its was useful for development but I didn't mean to include it in my patch submission.

Quoted 5 lines

Not sure if it makes sense at this point, but perhaps it's a good idea to move the mmc_loader() function into the CPU specific portion. As you know, the CPU itself has multiple SDHI hardware blocks, and because of that we want the common SDHI loader to be written to support any SDHI hardware block instance.

Wouldn't that mean moving all of arch/arm/boot/compressed/sdhi-shmobile.c into CPU specific code? That could easily be achived by just guarding its compilation with CONFIG_ARCH_SH7372 (as mmcif-sh7372.c already is) and perhaps renaming the file to sdhi-sh7372.c. We could probably move arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h back into sdhi-shmobile.c.

Quoted 5 lines

Right now the SDHI_BASE variable is limiting the shared SDHI loader code to a fixed hardware block instance. That's fine because we only boot from a single SDHI hardware block instance on sh7372, but future processors most likely support selecting boot SDHI hardware block instance.

So mmc_loader() would need to take SDHI_BASE as an argument? That sounds like a fairly small amount of refactoring.

How do you envisage that the hardware block would be selected? At compile time through Kconfig? If so the current #define mechanism might be sufficient.

Quoted 2 lines

Apart from those minor bits I think the code is getting into a really good shape!

Thanks

maintainer
#8 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Quoted 77 lines · Simon Horman
Quoted 67 lines · Magnus Damm
Quoted 66 lines · Simon Horman

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. ?This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
?As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
?+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
?+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. ?Thanks to Magnus Damm.
---

(quoted diff) +28 -0
+asmlinkage void mmc_loader(unsigned short *buf, unsigned long len)
+{
+ ? ? ? int high_capacity;
+
+ ? ? ? mmc_init_progress();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_ENTER);
+ ? ? ? sdhi_boot_enter();
+
+ ? ? ? /* setup SDHI hardware */
+ ? ? ? mmc_update_progress(MMC_PROGRESS_INIT);
+ ? ? ? high_capacity = sdhi_boot_init(SDHI_BASE);
+ ? ? ? if (high_capacity < 0)
+ ? ? ? ? ? ? ? goto err;
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_LOAD);
+ ? ? ? /* load kernel */
+ ? ? ? if (sdhi_boot_do_read(SDHI_BASE, high_capacity,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0, /* Kernel is at block 1 */
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? (len + TMIO_BBS - 1) / TMIO_BBS, buf))
+ ? ? ? ? ? ? ? goto err;
+
+ ? ? ? sdhi_boot_cleanup();
+
+ ? ? ? mmc_update_progress(MMC_PROGRESS_DONE);
+
+ ? ? ? return;
+err:
Quoted 8 lines

Review

Quoted 4 lines

+ ? ? ? __raw_writel(__raw_readl(PORTR031_000DR) | 1, PORTR031_000DR);
+ ? ? ? for(;;);

(quoted diff) +2 -0
+
+}

Sorry for not catching this earlier, but this __raw_writel() to PORTR031_000DR is cpu specific as well. So please move that to the CPU specific code.

Quoted 2 lines

I will just remove that code, its was useful for development but I didn't mean to include it in my patch submission.

Ok, good!

Quoted 6 lines
Quoted 5 lines

Not sure if it makes sense at this point, but perhaps it's a good idea to move the mmc_loader() function into the CPU specific portion. As you know, the CPU itself has multiple SDHI hardware blocks, and because of that we want the common SDHI loader to be written to support any SDHI hardware block instance.

Quoted 7 lines

Wouldn't that mean moving all of arch/arm/boot/compressed/sdhi-shmobile.c into CPU specific code? That could easily be achived by just guarding its compilation with CONFIG_ARCH_SH7372 (as mmcif-sh7372.c already is) and perhaps renaming the file to sdhi-sh7372.c. We could probably move arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h back into sdhi-shmobile.c.

No, I didn't mean moving all the SDHI loader code into the CPU specific place - just the mmc_loader() function.

Quoted 8 lines
Quoted 5 lines

Right now the SDHI_BASE variable is limiting the shared SDHI loader code to a fixed hardware block instance. That's fine because we only boot from a single SDHI hardware block instance on sh7372, but future processors most likely support selecting boot SDHI hardware block instance.

So mmc_loader() would need to take SDHI_BASE as an argument? That sounds like a fairly small amount of refactoring.

Yes, that's maybe more realistic, I'm not sure. Please remember that you probably want to select different GPIO pins for different SDHI instances, so you also need to adjust the sdhi_boot_enter()/sdhi_boot_cleanup() to receive SDHI_BASE as an argument too if you go down that route.

Quoted 3 lines

How do you envisage that the hardware block would be selected? At compile time through Kconfig? If so the current #define mechanism might be sufficient.

Not through Kconfig. I think you should use Kconfig to enable the SDHI loader, but you should be able to select the SDHI base address during run-time. Similar to how we enable platform device drivers with Kconfig but put the instance information in the platform device resource and data outside the driver.

So for instance, on some board we may want to read a GPIO pin at boot up time to select if we should boot from SDHI0 or SDHI1. I would like the SDHI loader to be designed so we can have support for multiple instances complied-in. Because of that I'd like to see the fixed SDHI_BASE disappear from the header, and letting the mmc_loader() function take the base address as an argument, or simply move the mmc_loader() function out of the SDHI loader code to give CPU specific and/or board specific code freedom to select which ever SDHI hardware block instance(s) they want to load from.

Perhaps this would require some serious refactoring?

Thanks,

/ magnus

author
#9 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Quoted 2 lines · Magnus Damm
Quoted 1 line · Simon Horman

On Wed, Mar 16, 2011 at 09:37:50AM +0900, Magnus Damm wrote:

[snip]

Quoted 52 lines
Quoted 6 lines
Quoted 5 lines

Not sure if it makes sense at this point, but perhaps it's a good idea to move the mmc_loader() function into the CPU specific portion. As you know, the CPU itself has multiple SDHI hardware blocks, and because of that we want the common SDHI loader to be written to support any SDHI hardware block instance.

Quoted 7 lines

Wouldn't that mean moving all of arch/arm/boot/compressed/sdhi-shmobile.c into CPU specific code? That could easily be achived by just guarding its compilation with CONFIG_ARCH_SH7372 (as mmcif-sh7372.c already is) and perhaps renaming the file to sdhi-sh7372.c. We could probably move arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h back into sdhi-shmobile.c.

No, I didn't mean moving all the SDHI loader code into the CPU specific place - just the mmc_loader() function.

Quoted 8 lines
Quoted 5 lines

Right now the SDHI_BASE variable is limiting the shared SDHI loader code to a fixed hardware block instance. That's fine because we only boot from a single SDHI hardware block instance on sh7372, but future processors most likely support selecting boot SDHI hardware block instance.

So mmc_loader() would need to take SDHI_BASE as an argument? That sounds like a fairly small amount of refactoring.

Yes, that's maybe more realistic, I'm not sure. Please remember that you probably want to select different GPIO pins for different SDHI instances, so you also need to adjust the sdhi_boot_enter()/sdhi_boot_cleanup() to receive SDHI_BASE as an argument too if you go down that route.

Quoted 3 lines

How do you envisage that the hardware block would be selected? At compile time through Kconfig? If so the current #define mechanism might be sufficient.

Not through Kconfig. I think you should use Kconfig to enable the SDHI loader, but you should be able to select the SDHI base address during run-time. Similar to how we enable platform device drivers with Kconfig but put the instance information in the platform device resource and data outside the driver.

So for instance, on some board we may want to read a GPIO pin at boot up time to select if we should boot from SDHI0 or SDHI1. I would like the SDHI loader to be designed so we can have support for multiple instances complied-in. Because of that I'd like to see the fixed SDHI_BASE disappear from the header, and letting the mmc_loader() function take the base address as an argument, or simply move the mmc_loader() function out of the SDHI loader code to give CPU specific and/or board specific code freedom to select which ever SDHI hardware block instance(s) they want to load from.

Quoted 1 line

Perhaps this would require some serious refactoring?

Either making mmc_loader() CPU specific or allowing it to take an argument should be pretty straight forward.

However, it is entirely unclear to me how the argument to mmc_loader() would be supplied or alternatively the variant of mmc_loader() be selected at run-time.

This code runs in very early boot. And as such I think that the two major options are to either compile code in or pull it out of a register somehow. We really don't have a whole lot of code that runs before mmc_loader() that could do any kind of setup.

maintainer
#10 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Quoted 22 lines · Simon Horman
Quoted 21 lines · Magnus Damm
Quoted 3 lines · Simon Horman

How do you envisage that the hardware block would be selected? At compile time through Kconfig? If so the current #define mechanism might be sufficient.

Not through Kconfig. I think you should use Kconfig to enable the SDHI loader, but you should be able to select the SDHI base address during run-time. Similar to how we enable platform device drivers with Kconfig but put the instance information in the platform device resource and data outside the driver.

So for instance, on some board we may want to read a GPIO pin at boot up time to select if we should boot from SDHI0 or SDHI1. I would like the SDHI loader to be designed so we can have support for multiple instances complied-in. Because of that I'd like to see the fixed SDHI_BASE disappear from the header, and letting the mmc_loader() function take the base address as an argument, or simply move the mmc_loader() function out of the SDHI loader code to give CPU specific and/or board specific code freedom to select which ever SDHI hardware block instance(s) they want to load from.

Quoted 4 lines
Quoted 1 line

Perhaps this would require some serious refactoring?

Either making mmc_loader() CPU specific or allowing it to take an argument should be pretty straight forward.

Good!

Quoted 3 lines

However, it is entirely unclear to me how the argument to mmc_loader() would be supplied or alternatively the variant of mmc_loader() be selected at run-time.

At this point, the sh7372 specific could would simply pass the same SDHI base address that your code is using. No special selection needed. Just compile it in.

In the future we may want to read out the boot mode pins and select base address accordingly. It's too early to tell exactly what to do with the CPU specific bits for future processors, but at least we can make sure that the SDHI loader isn't tied to a single SDHI instance by design.

Quoted 4 lines

This code runs in very early boot. And as such I think that the two major options are to either compile code in or pull it out of a register somehow. We really don't have a whole lot of code that runs before mmc_loader() that could do any kind of setup.

Compiling in the base address is fine for sh7372, but please put that base address in the CPU specific code and feed that to the more generic SDHI loader using a function argument.

Do you understand what I'm trying to do, or am I just going in circles? =)

Thanks,

/ magnus

author
#11 lore raw

PATCH v4 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

Quoted 30 lines · Magnus Damm
Quoted 22 lines · Simon Horman
Quoted 21 lines · Magnus Damm
Quoted 3 lines · Simon Horman

How do you envisage that the hardware block would be selected? At compile time through Kconfig? If so the current #define mechanism might be sufficient.

Not through Kconfig. I think you should use Kconfig to enable the SDHI loader, but you should be able to select the SDHI base address during run-time. Similar to how we enable platform device drivers with Kconfig but put the instance information in the platform device resource and data outside the driver.

So for instance, on some board we may want to read a GPIO pin at boot up time to select if we should boot from SDHI0 or SDHI1. I would like the SDHI loader to be designed so we can have support for multiple instances complied-in. Because of that I'd like to see the fixed SDHI_BASE disappear from the header, and letting the mmc_loader() function take the base address as an argument, or simply move the mmc_loader() function out of the SDHI loader code to give CPU specific and/or board specific code freedom to select which ever SDHI hardware block instance(s) they want to load from.

Quoted 4 lines
Quoted 1 line

Perhaps this would require some serious refactoring?

Either making mmc_loader() CPU specific or allowing it to take an argument should be pretty straight forward.

Good!

Quoted 7 lines
Quoted 3 lines

However, it is entirely unclear to me how the argument to mmc_loader() would be supplied or alternatively the variant of mmc_loader() be selected at run-time.

At this point, the sh7372 specific could would simply pass the same SDHI base address that your code is using. No special selection needed. Just compile it in.

Understood

Quoted 5 lines

In the future we may want to read out the boot mode pins and select base address accordingly. It's too early to tell exactly what to do with the CPU specific bits for future processors, but at least we can make sure that the SDHI loader isn't tied to a single SDHI instance by design.

Ok, that is fine. I agree its too early to tell exactly what to do beyond refactoring mmc_loader() at this point.

Quoted 10 lines
Quoted 4 lines

This code runs in very early boot. And as such I think that the two major options are to either compile code in or pull it out of a register somehow. We really don't have a whole lot of code that runs before mmc_loader() that could do any kind of setup.

Compiling in the base address is fine for sh7372, but please put that base address in the CPU specific code and feed that to the more generic SDHI loader using a function argument.

Do you understand what I'm trying to do, or am I just going in circles? =)

I feared we would be going in circles, but I think we have averted that :-)

author
#12 lore raw

PATCH v5 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on the for-next branch of
Russell King's linux-2.6-arm tree

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. Thanks to Magnus Damm.

v5
* Move mmc_loader into board-specific code
As suggested by Magnus Damm.

---
 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt    |   43 ++
 arch/arm/Kconfig                                  |   33 ++-
 arch/arm/boot/compressed/Makefile                 |   10 +-
 arch/arm/boot/compressed/head-shmobile.S          |   12 +-
 arch/arm/boot/compressed/mmcif-sh7372.c           |    2 +-
 arch/arm/boot/compressed/sdhi-sh7372.c            |   95 +++++
 arch/arm/boot/compressed/sdhi-shmobile.c          |  449 +++++++++++++++++++++
 arch/arm/boot/compressed/sdhi-shmobile.h          |   11 +
 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h |   21 +
 arch/arm/mach-shmobile/include/mach/sdhi.h        |   16 +
 arch/sh/boot/romimage/mmcif-sh7724.c              |    2 +-
 11 files changed, 676 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt
 create mode 100644 arch/arm/boot/compressed/sdhi-sh7372.c
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.c
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi.h
Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt new file +43 -0
new file mode 100644
index 0000000..dbd21ef
@@ -0,0 +1,43 @@
+ROM-able zImage boot from eSD
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and
+SuperH Mobile ARM will to boot directly from the SDHI hardware block.
+
+This is achieved by the mask ROM loading the first portion of the image into
+MERAM and then jumping to it. This portion contains loader code which
+copies the entire image to SDRAM and jumps to it. From there the zImage
+boot code proceeds as normal, uncompressing the image into its final
+location and then jumping to it.
+
+This code has been tested on an mackerel board using the developer 1A eSD
+boot mode which is configured using the following jumper settings.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x| |x|x|
+S4 -+-+-+-+-+-+-+-
+    | | | |x| | |x on
+
+The eSD card needs to be present in SDHI slot 1 (CN7).
+As such S1 and S33 also need to be configured as per
+the notes in arch/arm/mach-shmobile/board-mackerel.c.
+
+A partial zImage must be written to physical partition #1 (boot)
+of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to
+accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 count=9
+
+A full copy of _the same_ zImage should be written to physical partition #1
+(boot) of the eSD@sector 0. This should _not_ be in vrl4 format.
+
+	vrl4 < zImage | dd of=/dev/sdX bs=512
+
+Note: The commands above assume that the physical partition has been
+switched. No such facility currently exists in the Linux Kernel.
+
+Physical partitions are described in the eSD specification.  At the time of
+writing they are not the same as partitions that are typically configured
+using fdisk and visible through /proc/partitions
+
arch/arm/Kconfig +25 -8
index 574ce60..fcaffd2 100644
@@ -1685,17 +1685,34 @@ config ZBOOT_ROM
 	  Say Y here if you intend to execute your compressed kernel image
 	  (zImage) directly from ROM or flash.  If unsure, say N.
 
+choice
+	prompt "Include SD/MMC loader in zImage (EXPERIMENTAL)"
+	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
+	default ZBOOT_ROM_NONE
+	help
+	  Include experimental SD/MMC loading code in the ROM-able zImage.
+	  With this enabled it is possible to write the the ROM-able zImage
+	  kernel image to an MMC or SD card and boot the kernel straight
+	  from the reset vector. At reset the processor Mask ROM will load
+	  the first part of the the ROM-able zImage which in turn loads the
+	  rest the kernel image to RAM.
+
+config ZBOOT_ROM_NONE
+	bool "No SD/MMC loader in zImage (EXPERIMENTAL)"
+	help
+	  Do not load image from SD or MMC
+
 config ZBOOT_ROM_MMCIF
 	bool "Include MMCIF loader in zImage (EXPERIMENTAL)"
-	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
 	help
-	  Say Y here to include experimental MMCIF loading code in the
-	  ROM-able zImage. With this enabled it is possible to write the
-	  the ROM-able zImage kernel image to an MMC card and boot the
-	  kernel straight from the reset vector. At reset the processor
-	  Mask ROM will load the first part of the the ROM-able zImage
-	  which in turn loads the rest the kernel image to RAM using the
-	  MMCIF hardware block.
+	  Load image from MMCIF hardware block.
+
+config ZBOOT_ROM_SH_MOBILE_SDHI
+	bool "Include SuperH Mobile SDHI loader in zImage (EXPERIMENTAL)"
+	help
+	  Load image from SDHI hardware block
+
+endchoice
 
 config CMDLINE
 	string "Default kernel command string"
arch/arm/boot/compressed/Makefile +8 -2
index f9f77c6..ba60cdd 100644
@@ -6,13 +6,19 @@
 
 OBJS		=
 
-# Ensure that mmcif loader code appears early in the image
+# Ensure that MMCIF loader code appears early in the image
 # to minimise that number of bocks that have to be read in
 # order to load it.
 ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
-ifeq ($(CONFIG_ARCH_SH7372),y)
 OBJS		+= mmcif-sh7372.o
 endif
+
+# Ensure that SDHI loader code appears early in the image
+# to minimise that number of bocks that have to be read in
+# order to load it.
+ifeq ($(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI),y)
+OBJS		+= sdhi-shmobile.o
+OBJS		+= sdhi-sh7372.o
 endif
 
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
arch/arm/boot/compressed/head-shmobile.S +6 -6
index c943d2e..fe3719b 100644
@@ -25,14 +25,14 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-#ifdef CONFIG_ZBOOT_ROM_MMCIF
-	/* Load image from MMC */
-	adr	sp, __tmp_stack + 128
+#if defined(CONFIG_ZBOOT_ROM_MMCIF) || defined(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI)
+	/* Load image from MMC/SD */
+	adr	sp, __tmp_stack + 256
 	ldr	r0, __image_start
 	ldr	r1, __image_end
 	subs	r1, r1, r0
 	ldr	r0, __load_base
-	bl	mmcif_loader
+	bl	mmc_loader
 
 	/* Jump to loaded code */
 	ldr	r0, __loaded

@@ -51,9 +51,9 @@ __loaded:
 	.long	__continue
 	.align
 __tmp_stack:
-	.space	128
+	.space	256
 __continue:
-#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+#endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
 	b	1f
 __atags:@ tag #1
arch/arm/boot/compressed/mmcif-sh7372.c +1 -1
index 86b26a1..08fc0f3 100644
@@ -39,7 +39,7 @@
  * to an MMC card
  * # dd if=vrl4.out of=/dev/sdx bs=512 seek=1
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long len)
 {
 	mmc_init_progress();
 	mmc_update_progress(MMC_PROGRESS_ENTER);
arch/arm/boot/compressed/sdhi-sh7372.c new file +95 -0

95 lines not on this page · raw message

arch/arm/boot/compressed/sdhi-shmobile.c new file +449 -0

449 lines not on this page · raw message

arch/arm/boot/compressed/sdhi-shmobile.h new file +11 -0
new file mode 100644
index 0000000..92eaa09
@@ -0,0 +1,11 @@
+#ifndef SDHI_MOBILE_H
+#define SDHI_MOBILE_H
+
+#include <linux/compiler.h>
+
+int sdhi_boot_do_read(void __iomem *base, int high_capacity,
+		      unsigned long offset, unsigned short count,
+		      unsigned short *buf);
+int sdhi_boot_init(void __iomem *base);
+
+#endif
arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h new file +21 -0
new file mode 100644
index 0000000..4a81b01
@@ -0,0 +1,21 @@
+#ifndef SDHI_SH7372_H
+#define SDHI_SH7372_H
+
+#define SDGENCNTA       0xfe40009c
+
+/* The countdown of SDGENCNTA is controlled by
+ * ZB3D2CLK which runs at 149.5MHz.
+ * That is 149.5ticks/us. Approximate this as 150ticks/us.
+ */
+static void udelay(int us)
+{
+	__raw_writel(us * 150, SDGENCNTA);
+	while(__raw_readl(SDGENCNTA)) ;
+}
+
+static void msleep(int ms)
+{
+	udelay(ms * 1000);
+}
+
+#endif
arch/arm/mach-shmobile/include/mach/sdhi.h new file +16 -0
new file mode 100644
index 0000000..0ec9e69
@@ -0,0 +1,16 @@
+#ifndef SDHI_H
+#define SDHI_H
+
+/**************************************************
+ *
+ *		CPU specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_ARCH_SH7372
+#include "mach/sdhi-sh7372.h"
+#else
+#error "unsupported CPU."
+#endif
+
+#endif /* SDHI_H */
arch/sh/boot/romimage/mmcif-sh7724.c +1 -1
index 1d13335..17c4ed3 100644
@@ -27,7 +27,7 @@
  * use the following line to write the romImage to an MMC card
  * # dd if=arch/sh/boot/romImage of=/dev/sdx bs=512 seek=512
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long no_bytes)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long no_bytes)
 {
 	mmcif_update_progress(MMC_PROGRESS_ENTER);
Signature · 1 line
1.7.2.3
author
#13 lore raw

PATCH v6 4/4 mmc, ARM: Add zboot from eSD support for SuperH Mobile ARM

This allows a ROM-able zImage to be written to eSD and for SuperH Mobile ARM to boot directly from the SDHI hardware block.

This is achieved by the MaskROM loading the first portion of the image into MERAM and then jumping to it. This portion contains loader code which copies the entire image to SDRAM and jumps to it. From there the zImage boot code proceeds as normal, uncompressing the image into its final location and then jumping to it.

Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
Cc Kuninori Morimoto <[email protected]>
Signed-off-by Simon Horman <[email protected]>

---

This patch is based on Linus's tree, commit
f741a79 ("Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse")

It also has the following prerequisite patches:
* mmc: tmio_mmc: Move some defines into a shared header
I have asked Guennadi to add this to his current driver-split patch-set
* mmc, ARM: Rename SuperH Mobile ARM zboot helpers
I have reposted this separately and asked Paul to merge it
mmc: Add MMC_PROGRESS_*
I have reposted this separately and asked Paul to merge it

v2
* Consistently use __raw_readw(). As pointed out by Paul Mundt

v3
* Remove mmcif_update_progress2(), it was for debugging during development
* Move CPU specific code into mach/sdhi.h
As requested by Magnus Damm
* Use linux/mmc/tmio.h now that it exists
* Remove SDHI_EXT_SWAP, it is unused
* Replace use of MMCIF_PROGRESS_* with MMC_PROGRESS_*
* Don't include linux/mmc/sh_mmcif.h
+ Replace use of MMCIF_CE_RESP_CMD12 with RESP_CMD12
+ Include linux/io.h

v4
* Move definition of SDHI_BASE into CPU-specific code. Thanks to Magnus Damm.

v5
* Move mmc_loader into board-specific code
As suggested by Magnus Damm.

v6
* Don't change the name of mmcif_loader to mmc_loader in arch/sh/boot/romimage/mmcif-sh7724.c
That code is unrelated to this change and changing the name without updating the caller introduces a build failure.
* Fix shdi -> sdhi typos

---
 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt    |   43 ++
 arch/arm/Kconfig                                  |   33 ++-
 arch/arm/boot/compressed/Makefile                 |   10 +-
 arch/arm/boot/compressed/head-shmobile.S          |   24 +-
 arch/arm/boot/compressed/mmcif-sh7372.c           |    2 +-
 arch/arm/boot/compressed/sdhi-sh7372.c            |   96 +++++
 arch/arm/boot/compressed/sdhi-shmobile.c          |  449 +++++++++++++++++++++
 arch/arm/boot/compressed/sdhi-shmobile.h          |   11 +
 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h |   21 +
 arch/arm/mach-shmobile/include/mach/sdhi.h        |   16 +
 10 files changed, 688 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt
 create mode 100644 arch/arm/boot/compressed/sdhi-sh7372.c
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.c
 create mode 100644 arch/arm/boot/compressed/sdhi-shmobile.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h
 create mode 100644 arch/arm/mach-shmobile/include/mach/sdhi.h
Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt new file +43 -0
new file mode 100644
index 0000000..dbd21ef
@@ -0,0 +1,43 @@
+ROM-able zImage boot from eSD
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and
+SuperH Mobile ARM will to boot directly from the SDHI hardware block.
+
+This is achieved by the mask ROM loading the first portion of the image into
+MERAM and then jumping to it. This portion contains loader code which
+copies the entire image to SDRAM and jumps to it. From there the zImage
+boot code proceeds as normal, uncompressing the image into its final
+location and then jumping to it.
+
+This code has been tested on an mackerel board using the developer 1A eSD
+boot mode which is configured using the following jumper settings.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x| |x|x|
+S4 -+-+-+-+-+-+-+-
+    | | | |x| | |x on
+
+The eSD card needs to be present in SDHI slot 1 (CN7).
+As such S1 and S33 also need to be configured as per
+the notes in arch/arm/mach-shmobile/board-mackerel.c.
+
+A partial zImage must be written to physical partition #1 (boot)
+of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to
+accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 count=9
+
+A full copy of _the same_ zImage should be written to physical partition #1
+(boot) of the eSD@sector 0. This should _not_ be in vrl4 format.
+
+	vrl4 < zImage | dd of=/dev/sdX bs=512
+
+Note: The commands above assume that the physical partition has been
+switched. No such facility currently exists in the Linux Kernel.
+
+Physical partitions are described in the eSD specification.  At the time of
+writing they are not the same as partitions that are typically configured
+using fdisk and visible through /proc/partitions
+
arch/arm/Kconfig +25 -8
index 599e163..6aea903 100644
@@ -1715,17 +1715,34 @@ config ZBOOT_ROM
 	  Say Y here if you intend to execute your compressed kernel image
 	  (zImage) directly from ROM or flash.  If unsure, say N.
 
+choice
+	prompt "Include SD/MMC loader in zImage (EXPERIMENTAL)"
+	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
+	default ZBOOT_ROM_NONE
+	help
+	  Include experimental SD/MMC loading code in the ROM-able zImage.
+	  With this enabled it is possible to write the the ROM-able zImage
+	  kernel image to an MMC or SD card and boot the kernel straight
+	  from the reset vector. At reset the processor Mask ROM will load
+	  the first part of the the ROM-able zImage which in turn loads the
+	  rest the kernel image to RAM.
+
+config ZBOOT_ROM_NONE
+	bool "No SD/MMC loader in zImage (EXPERIMENTAL)"
+	help
+	  Do not load image from SD or MMC
+
 config ZBOOT_ROM_MMCIF
 	bool "Include MMCIF loader in zImage (EXPERIMENTAL)"
-	depends on ZBOOT_ROM && ARCH_SH7372 && EXPERIMENTAL
 	help
-	  Say Y here to include experimental MMCIF loading code in the
-	  ROM-able zImage. With this enabled it is possible to write the
-	  the ROM-able zImage kernel image to an MMC card and boot the
-	  kernel straight from the reset vector. At reset the processor
-	  Mask ROM will load the first part of the the ROM-able zImage
-	  which in turn loads the rest the kernel image to RAM using the
-	  MMCIF hardware block.
+	  Load image from MMCIF hardware block.
+
+config ZBOOT_ROM_SH_MOBILE_SDHI
+	bool "Include SuperH Mobile SDHI loader in zImage (EXPERIMENTAL)"
+	help
+	  Load image from SDHI hardware block
+
+endchoice
 
 config CMDLINE
 	string "Default kernel command string"
arch/arm/boot/compressed/Makefile +8 -2
index 8ebbb51..5249d50 100644
@@ -6,13 +6,19 @@
 
 OBJS		=
 
-# Ensure that mmcif loader code appears early in the image
+# Ensure that MMCIF loader code appears early in the image
 # to minimise that number of bocks that have to be read in
 # order to load it.
 ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
-ifeq ($(CONFIG_ARCH_SH7372),y)
 OBJS		+= mmcif-sh7372.o
 endif
+
+# Ensure that SDHI loader code appears early in the image
+# to minimise that number of bocks that have to be read in
+# order to load it.
+ifeq ($(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI),y)
+OBJS		+= sdhi-shmobile.o
+OBJS		+= sdhi-sh7372.o
 endif
 
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
arch/arm/boot/compressed/head-shmobile.S +18 -6
index c943d2e..3d07519 100644
@@ -25,14 +25,26 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-#ifdef CONFIG_ZBOOT_ROM_MMCIF
-	/* Load image from MMC */
-	adr	sp, __tmp_stack + 128
+#if defined(CONFIG_ZBOOT_ROM_MMCIF) || defined(CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI)
+	/* Load image from MMC/SD */
+	adr	sp, __tmp_stack + 256
 	ldr	r0, __image_start
 	ldr	r1, __image_end
 	subs	r1, r1, r0
 	ldr	r0, __load_base
-	bl	mmcif_loader
+	bl	mmc_loader
+
+	EB      0xe6051000 0x00000010
+	EB      0xe6051001 0x00000010
+	EB      0xe6051002 0x00000010
+__blink:
+	ED      0xe6055000 0x00000001
+	WAIT    200000 0xfe40009c
+	ED      0xe6055000 0x00000002
+	WAIT    200000 0xfe40009c
+	ED	0xe6055000 0x00000004
+	WAIT	200000 0xfe40009c
+	b __blink
 
 	/* Jump to loaded code */
 	ldr	r0, __loaded

@@ -51,9 +63,9 @@ __loaded:
 	.long	__continue
 	.align
 __tmp_stack:
-	.space	128
+	.space	256
 __continue:
-#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+#endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
 	b	1f
 __atags:@ tag #1
arch/arm/boot/compressed/mmcif-sh7372.c +1 -1
index 7453c83..b6f61d9 100644
@@ -40,7 +40,7 @@
  * to an MMC card
  * # dd if=vrl4.out of=/dev/sdx bs=512 seek=1
  */
-asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+asmlinkage void mmc_loader(unsigned char *buf, unsigned long len)
 {
 	mmc_init_progress();
 	mmc_update_progress(MMC_PROGRESS_ENTER);
arch/arm/boot/compressed/sdhi-sh7372.c new file +96 -0

96 lines not on this page · raw message

arch/arm/boot/compressed/sdhi-shmobile.c new file +449 -0

449 lines not on this page · raw message

arch/arm/boot/compressed/sdhi-shmobile.h new file +11 -0
new file mode 100644
index 0000000..92eaa09
@@ -0,0 +1,11 @@
+#ifndef SDHI_MOBILE_H
+#define SDHI_MOBILE_H
+
+#include <linux/compiler.h>
+
+int sdhi_boot_do_read(void __iomem *base, int high_capacity,
+		      unsigned long offset, unsigned short count,
+		      unsigned short *buf);
+int sdhi_boot_init(void __iomem *base);
+
+#endif
arch/arm/mach-shmobile/include/mach/sdhi-sh7372.h new file +21 -0
new file mode 100644
index 0000000..4a81b01
@@ -0,0 +1,21 @@
+#ifndef SDHI_SH7372_H
+#define SDHI_SH7372_H
+
+#define SDGENCNTA       0xfe40009c
+
+/* The countdown of SDGENCNTA is controlled by
+ * ZB3D2CLK which runs at 149.5MHz.
+ * That is 149.5ticks/us. Approximate this as 150ticks/us.
+ */
+static void udelay(int us)
+{
+	__raw_writel(us * 150, SDGENCNTA);
+	while(__raw_readl(SDGENCNTA)) ;
+}
+
+static void msleep(int ms)
+{
+	udelay(ms * 1000);
+}
+
+#endif
arch/arm/mach-shmobile/include/mach/sdhi.h new file +16 -0
new file mode 100644
index 0000000..0ec9e69
@@ -0,0 +1,16 @@
+#ifndef SDHI_H
+#define SDHI_H
+
+/**************************************************
+ *
+ *		CPU specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_ARCH_SH7372
+#include "mach/sdhi-sh7372.h"
+#else
+#error "unsupported CPU."
+#endif
+
+#endif /* SDHI_H */
Signature · 1 line
1.7.2.3