[patch 0/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[patch 0/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This short series allows a ROM-able zImage to be written to MMC and for
SuperH Mobile ARM to boot directly from the MMCIF hardware block.

The first two patches make minor preparatory changes to the MMCIF code.
The last patch contains the code to load from the MMCIF hardware block.

[patch 0/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This short series allows a ROM-able zImage to be written to MMC and for
SuperH Mobile ARM to boot directly from the MMCIF hardware block.

The first two patches make minor preparatory changes to the MMCIF code.
The last patch contains the code to load from the MMCIF hardware block.

[patch 0/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This short series allows a ROM-able zImage to be written to MMC and for
SuperH Mobile ARM to boot directly from the MMCIF hardware block.

The first two patches make minor preparatory changes to the MMCIF code.
The last patch contains the code to load from the MMCIF hardware block.

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

[-- Attachment #1: MMCIF_PROGRESS-header.patch --]
[-- Type: text/plain, Size: 1340 bytes --]

Allow MMCIF_PROGRESS_* to be shared.

Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

Index: linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c
===================================================================
--- linux-2.6-ap4.orig/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 08:59:11.000000000 +0900
+++ linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 08:59:16.000000000 +0900
@@ -21,9 +21,6 @@
 #define HIZCRC		0xa405015c
 #define DRVCRA		0xa405018a
 
-enum { MMCIF_PROGRESS_ENTER, MMCIF_PROGRESS_INIT,
-       MMCIF_PROGRESS_LOAD, MMCIF_PROGRESS_DONE };
-
 /* SH7724 specific MMCIF loader
  *
  * loads the romImage from an MMC card starting from block 512
Index: linux-2.6-ap4/include/linux/mmc/sh_mmcif.h
===================================================================
--- linux-2.6-ap4.orig/include/linux/mmc/sh_mmcif.h	2010-12-06 08:59:11.000000000 +0900
+++ linux-2.6-ap4/include/linux/mmc/sh_mmcif.h	2010-12-06 08:59:16.000000000 +0900
@@ -97,6 +97,9 @@ static inline void sh_mmcif_writel(void
 
 #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)
 {

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

An embedded and charset-unspecified text was scrubbed...
Name: MMCIF_PROGRESS-header.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101206/5613a8a3/attachment.ksh>

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

Allow MMCIF_PROGRESS_* to be shared.

Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

Index: linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c
=================================--- linux-2.6-ap4.orig/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 08:59:11.000000000 +0900
+++ linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 08:59:16.000000000 +0900
@@ -21,9 +21,6 @@
 #define HIZCRC		0xa405015c
 #define DRVCRA		0xa405018a
 
-enum { MMCIF_PROGRESS_ENTER, MMCIF_PROGRESS_INIT,
-       MMCIF_PROGRESS_LOAD, MMCIF_PROGRESS_DONE };
-
 /* SH7724 specific MMCIF loader
  *
  * loads the romImage from an MMC card starting from block 512
Index: linux-2.6-ap4/include/linux/mmc/sh_mmcif.h
=================================--- linux-2.6-ap4.orig/include/linux/mmc/sh_mmcif.h	2010-12-06 08:59:11.000000000 +0900
+++ linux-2.6-ap4/include/linux/mmc/sh_mmcif.h	2010-12-06 08:59:16.000000000 +0900
@@ -97,6 +97,9 @@ static inline void sh_mmcif_writel(void
 
 #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)
 {

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> Allow MMCIF_PROGRESS_* to be shared.
>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>

I'm a bit hesitant to this change. This because the progress really
hasn't anything to do with the MMCIF hardware block. The enum does use
the MMCIF prefix though, so I guess i should be silent. =)

In the future I can imagine that there will be more boards making use
of this feature, and other MMC/SD-capable hardware blocks that want to
support early loading. Perhaps moving the enum into the header like
you suggest is the easiest way forward. Unless there is any easy way
to share the same progress code between MMCIF and say SDHI.

Thanks,

/ magnus

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> Allow MMCIF_PROGRESS_* to be shared.
>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>

I'm a bit hesitant to this change. This because the progress really
hasn't anything to do with the MMCIF hardware block. The enum does use
the MMCIF prefix though, so I guess i should be silent. =)

In the future I can imagine that there will be more boards making use
of this feature, and other MMC/SD-capable hardware blocks that want to
support early loading. Perhaps moving the enum into the header like
you suggest is the easiest way forward. Unless there is any easy way
to share the same progress code between MMCIF and say SDHI.

Thanks,

/ magnus

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> Allow MMCIF_PROGRESS_* to be shared.
>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>

I'm a bit hesitant to this change. This because the progress really
hasn't anything to do with the MMCIF hardware block. The enum does use
the MMCIF prefix though, so I guess i should be silent. =)

In the future I can imagine that there will be more boards making use
of this feature, and other MMC/SD-capable hardware blocks that want to
support early loading. Perhaps moving the enum into the header like
you suggest is the easiest way forward. Unless there is any easy way
to share the same progress code between MMCIF and say SDHI.

Thanks,

/ magnus

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > Allow MMCIF_PROGRESS_* to be shared.
> >
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> I'm a bit hesitant to this change. This because the progress really
> hasn't anything to do with the MMCIF hardware block. The enum does use
> the MMCIF prefix though, so I guess i should be silent. =)
> 
> In the future I can imagine that there will be more boards making use
> of this feature, and other MMC/SD-capable hardware blocks that want to
> support early loading. Perhaps moving the enum into the header like
> you suggest is the easiest way forward. Unless there is any easy way
> to share the same progress code between MMCIF and say SDHI.

The way that I see things is that with the last patch in this series
there are two files using these enums, one under arch/sh and one under
arch/arm. They both relate to using MMCIF. And they both assume that
there are states we are interested in that can be usefully displayed.
If SHDI can make use of this it may make sense to move it somewhere
else at that time.

OTOH, its just 4 integers and this is really just debugging code.
I wouldn't be opposed to removing it altogether.

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > Allow MMCIF_PROGRESS_* to be shared.
> >
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> I'm a bit hesitant to this change. This because the progress really
> hasn't anything to do with the MMCIF hardware block. The enum does use
> the MMCIF prefix though, so I guess i should be silent. =)
> 
> In the future I can imagine that there will be more boards making use
> of this feature, and other MMC/SD-capable hardware blocks that want to
> support early loading. Perhaps moving the enum into the header like
> you suggest is the easiest way forward. Unless there is any easy way
> to share the same progress code between MMCIF and say SDHI.

The way that I see things is that with the last patch in this series
there are two files using these enums, one under arch/sh and one under
arch/arm. They both relate to using MMCIF. And they both assume that
there are states we are interested in that can be usefully displayed.
If SHDI can make use of this it may make sense to move it somewhere
else at that time.

OTOH, its just 4 integers and this is really just debugging code.
I wouldn't be opposed to removing it altogether.

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Simon Horman]

On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > Allow MMCIF_PROGRESS_* to be shared.
> >
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> I'm a bit hesitant to this change. This because the progress really
> hasn't anything to do with the MMCIF hardware block. The enum does use
> the MMCIF prefix though, so I guess i should be silent. =)
> 
> In the future I can imagine that there will be more boards making use
> of this feature, and other MMC/SD-capable hardware blocks that want to
> support early loading. Perhaps moving the enum into the header like
> you suggest is the easiest way forward. Unless there is any easy way
> to share the same progress code between MMCIF and say SDHI.

The way that I see things is that with the last patch in this series
there are two files using these enums, one under arch/sh and one under
arch/arm. They both relate to using MMCIF. And they both assume that
there are states we are interested in that can be usefully displayed.
If SHDI can make use of this it may make sense to move it somewhere
else at that time.

OTOH, its just 4 integers and this is really just debugging code.
I wouldn't be opposed to removing it altogether.

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:28 AM, Simon Horman <simon@horms.net> wrote:
> On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > Allow MMCIF_PROGRESS_* to be shared.
>> >
>> > Cc: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>>
>> I'm a bit hesitant to this change. This because the progress really
>> hasn't anything to do with the MMCIF hardware block. The enum does use
>> the MMCIF prefix though, so I guess i should be silent. =)
>>
>> In the future I can imagine that there will be more boards making use
>> of this feature, and other MMC/SD-capable hardware blocks that want to
>> support early loading. Perhaps moving the enum into the header like
>> you suggest is the easiest way forward. Unless there is any easy way
>> to share the same progress code between MMCIF and say SDHI.
>
> The way that I see things is that with the last patch in this series
> there are two files using these enums, one under arch/sh and one under
> arch/arm. They both relate to using MMCIF. And they both assume that
> there are states we are interested in that can be usefully displayed.

Sure.

> If SHDI can make use of this it may make sense to move it somewhere
> else at that time.

Yeah, dealing with it at that point is probably the easiest.

> OTOH, its just 4 integers and this is really just debugging code.
> I wouldn't be opposed to removing it altogether.

I'd rather keep it. The MMC loader code is a rather new development so
having some early debug output option makes sense.

Thanks,

/ magnus

[patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:28 AM, Simon Horman <simon@horms.net> wrote:
> On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > Allow MMCIF_PROGRESS_* to be shared.
>> >
>> > Cc: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>>
>> I'm a bit hesitant to this change. This because the progress really
>> hasn't anything to do with the MMCIF hardware block. The enum does use
>> the MMCIF prefix though, so I guess i should be silent. =)
>>
>> In the future I can imagine that there will be more boards making use
>> of this feature, and other MMC/SD-capable hardware blocks that want to
>> support early loading. Perhaps moving the enum into the header like
>> you suggest is the easiest way forward. Unless there is any easy way
>> to share the same progress code between MMCIF and say SDHI.
>
> The way that I see things is that with the last patch in this series
> there are two files using these enums, one under arch/sh and one under
> arch/arm. They both relate to using MMCIF. And they both assume that
> there are states we are interested in that can be usefully displayed.

Sure.

> If SHDI can make use of this it may make sense to move it somewhere
> else at that time.

Yeah, dealing with it at that point is probably the easiest.

> OTOH, its just 4 integers and this is really just debugging code.
> I wouldn't be opposed to removing it altogether.

I'd rather keep it. The MMC loader code is a rather new development so
having some early debug output option makes sense.

Thanks,

/ magnus

Re: [patch 1/3] mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:28 AM, Simon Horman <simon@horms.net> wrote:
> On Mon, Dec 06, 2010 at 09:57:17AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > Allow MMCIF_PROGRESS_* to be shared.
>> >
>> > Cc: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>>
>> I'm a bit hesitant to this change. This because the progress really
>> hasn't anything to do with the MMCIF hardware block. The enum does use
>> the MMCIF prefix though, so I guess i should be silent. =)
>>
>> In the future I can imagine that there will be more boards making use
>> of this feature, and other MMC/SD-capable hardware blocks that want to
>> support early loading. Perhaps moving the enum into the header like
>> you suggest is the easiest way forward. Unless there is any easy way
>> to share the same progress code between MMCIF and say SDHI.
>
> The way that I see things is that with the last patch in this series
> there are two files using these enums, one under arch/sh and one under
> arch/arm. They both relate to using MMCIF. And they both assume that
> there are states we are interested in that can be usefully displayed.

Sure.

> If SHDI can make use of this it may make sense to move it somewhere
> else at that time.

Yeah, dealing with it at that point is probably the easiest.

> OTOH, its just 4 integers and this is really just debugging code.
> I wouldn't be opposed to removing it altogether.

I'd rather keep it. The MMC loader code is a rather new development so
having some early debug output option makes sense.

Thanks,

/ magnus

[patch 2/3] mmc, sh: Remove sh_mmcif_boot_slurp()

[Simon Horman]

[-- Attachment #1: no-slurp.patch --]
[-- Type: text/plain, Size: 3067 bytes --]

As the only caller of sh_mmcif_boot_do_read() is
sh_mmcif_boot_slurp() the configuration portion of
sh_mmcif_boot_slurp() can be merged into sh_mmcif_boot_do_read().

Once this is done sh_mmcif_boot_slurp() is only a call
to sh_mmcif_boot_do_read() with platform specific information -
the offset that images are stored on MMC. So make the
sh_mmcif_boot_do_read() call directly from platform code
and remove sh_mmcif_boot_slurp() altogether.

Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

This patch applies on top of
"sh, mmc: Use defines when setting CE_CLK_CTR"
which has been merged into the common/mmcif
branch of Paul Mundt's sh-2.6 tree.
Index: linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c
===================================================================
--- linux-2.6-ap4.orig/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 09:08:13.000000000 +0900
+++ linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 09:08:14.000000000 +0900
@@ -60,7 +60,9 @@ asmlinkage void mmcif_loader(unsigned ch
 	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
 
 	/* load kernel via MMCIF interface */
-	sh_mmcif_boot_slurp(MMCIF_BASE, buf, no_bytes);
+	sh_mmcif_boot_do_read(MMCIF_BASE, 512,
+	                      (no_bytes + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS,
+			      buf);
 
 	/* disable clock to the MMCIF hardware block */
 	__raw_writel(__raw_readl(MSTPCR2) | 0x20000000, MSTPCR2);
Index: linux-2.6-ap4/include/linux/mmc/sh_mmcif.h
===================================================================
--- linux-2.6-ap4.orig/include/linux/mmc/sh_mmcif.h	2010-12-06 09:08:13.000000000 +0900
+++ linux-2.6-ap4/include/linux/mmc/sh_mmcif.h	2010-12-06 09:08:14.000000000 +0900
@@ -162,6 +162,17 @@ static inline int sh_mmcif_boot_do_read(
 	unsigned long k;
 	int ret = 0;
 
+	/* In data transfer mode: Set clock to Bus clock/4 (about 20Mhz) */
+	sh_mmcif_writel(base, MMCIF_CE_CLK_CTRL,
+			CLK_ENABLE | CLKDIV_4 | SRSPTO_256 |
+			SRBSYTO_29 | SRWDTO_29 | SCCSTO_29);
+
+	/* CMD9 - Get CSD */
+	sh_mmcif_boot_cmd(base, 0x09806000, 0x00010000);
+
+	/* CMD7 - Select the card */
+	sh_mmcif_boot_cmd(base, 0x07400000, 0x00010000);
+
 	/* CMD16 - Set the block size */
 	sh_mmcif_boot_cmd(base, 0x10400000, SH_MMCIF_BBS);
 
@@ -205,27 +216,4 @@ static inline void sh_mmcif_boot_init(vo
 	sh_mmcif_boot_cmd(base, 0x03400040, 0x00010000);
 }
 
-static inline void sh_mmcif_boot_slurp(void __iomem *base,
-				       unsigned char *buf,
-				       unsigned long no_bytes)
-{
-	unsigned long tmp;
-
-	/* In data transfer mode: Set clock to Bus clock/4 (about 20Mhz) */
-	sh_mmcif_writel(base, MMCIF_CE_CLK_CTRL,
-			CLK_ENABLE | CLKDIV_4 | SRSPTO_256 |
-			SRBSYTO_29 | SRWDTO_29 | SCCSTO_29);
-
-	/* CMD9 - Get CSD */
-	sh_mmcif_boot_cmd(base, 0x09806000, 0x00010000);
-
-	/* CMD7 - Select the card */
-	sh_mmcif_boot_cmd(base, 0x07400000, 0x00010000);
-
-	tmp = no_bytes / SH_MMCIF_BBS;
-	tmp += (no_bytes % SH_MMCIF_BBS) ? 1 : 0;
-
-	sh_mmcif_boot_do_read(base, 512, tmp, buf);
-}
-
 #endif /* __SH_MMCIF_H__ */

[patch 2/3] mmc, sh: Remove sh_mmcif_boot_slurp()

[Simon Horman]

An embedded and charset-unspecified text was scrubbed...
Name: no-slurp.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101206/24190f3a/attachment.ksh>

[patch 2/3] mmc, sh: Remove sh_mmcif_boot_slurp()

[Simon Horman]

As the only caller of sh_mmcif_boot_do_read() is
sh_mmcif_boot_slurp() the configuration portion of
sh_mmcif_boot_slurp() can be merged into sh_mmcif_boot_do_read().

Once this is done sh_mmcif_boot_slurp() is only a call
to sh_mmcif_boot_do_read() with platform specific information -
the offset that images are stored on MMC. So make the
sh_mmcif_boot_do_read() call directly from platform code
and remove sh_mmcif_boot_slurp() altogether.

Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

This patch applies on top of
"sh, mmc: Use defines when setting CE_CLK_CTR"
which has been merged into the common/mmcif
branch of Paul Mundt's sh-2.6 tree.
Index: linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c
=================================--- linux-2.6-ap4.orig/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 09:08:13.000000000 +0900
+++ linux-2.6-ap4/arch/sh/boot/romimage/mmcif-sh7724.c	2010-12-06 09:08:14.000000000 +0900
@@ -60,7 +60,9 @@ asmlinkage void mmcif_loader(unsigned ch
 	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
 
 	/* load kernel via MMCIF interface */
-	sh_mmcif_boot_slurp(MMCIF_BASE, buf, no_bytes);
+	sh_mmcif_boot_do_read(MMCIF_BASE, 512,
+	                      (no_bytes + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS,
+			      buf);
 
 	/* disable clock to the MMCIF hardware block */
 	__raw_writel(__raw_readl(MSTPCR2) | 0x20000000, MSTPCR2);
Index: linux-2.6-ap4/include/linux/mmc/sh_mmcif.h
=================================--- linux-2.6-ap4.orig/include/linux/mmc/sh_mmcif.h	2010-12-06 09:08:13.000000000 +0900
+++ linux-2.6-ap4/include/linux/mmc/sh_mmcif.h	2010-12-06 09:08:14.000000000 +0900
@@ -162,6 +162,17 @@ static inline int sh_mmcif_boot_do_read(
 	unsigned long k;
 	int ret = 0;
 
+	/* In data transfer mode: Set clock to Bus clock/4 (about 20Mhz) */
+	sh_mmcif_writel(base, MMCIF_CE_CLK_CTRL,
+			CLK_ENABLE | CLKDIV_4 | SRSPTO_256 |
+			SRBSYTO_29 | SRWDTO_29 | SCCSTO_29);
+
+	/* CMD9 - Get CSD */
+	sh_mmcif_boot_cmd(base, 0x09806000, 0x00010000);
+
+	/* CMD7 - Select the card */
+	sh_mmcif_boot_cmd(base, 0x07400000, 0x00010000);
+
 	/* CMD16 - Set the block size */
 	sh_mmcif_boot_cmd(base, 0x10400000, SH_MMCIF_BBS);
 
@@ -205,27 +216,4 @@ static inline void sh_mmcif_boot_init(vo
 	sh_mmcif_boot_cmd(base, 0x03400040, 0x00010000);
 }
 
-static inline void sh_mmcif_boot_slurp(void __iomem *base,
-				       unsigned char *buf,
-				       unsigned long no_bytes)
-{
-	unsigned long tmp;
-
-	/* In data transfer mode: Set clock to Bus clock/4 (about 20Mhz) */
-	sh_mmcif_writel(base, MMCIF_CE_CLK_CTRL,
-			CLK_ENABLE | CLKDIV_4 | SRSPTO_256 |
-			SRBSYTO_29 | SRWDTO_29 | SCCSTO_29);
-
-	/* CMD9 - Get CSD */
-	sh_mmcif_boot_cmd(base, 0x09806000, 0x00010000);
-
-	/* CMD7 - Select the card */
-	sh_mmcif_boot_cmd(base, 0x07400000, 0x00010000);
-
-	tmp = no_bytes / SH_MMCIF_BBS;
-	tmp += (no_bytes % SH_MMCIF_BBS) ? 1 : 0;
-
-	sh_mmcif_boot_do_read(base, 512, tmp, buf);
-}
-
 #endif /* __SH_MMCIF_H__ */

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

[-- Attachment #1: load-kernel-2.patch --]
[-- Type: text/plain, Size: 14578 bytes --]

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
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: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
SuperH Mobile ARM" which has been merged into the devel branch
of Russell King's linux-2.6-arm tree.

Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,99 @@
+/*
+ * sh7372 MMCIF loader
+ *
+ * Copyright (C) 2010 Magnus Damm
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/mmc/sh_mmcif.h>
+#include <mach/mmcif.h>
+
+#define MMCIF_BASE      (void __iomem *)0xe6bd0000
+
+#define PORT84CR	0xe6050054
+#define PORT85CR	0xe6050055
+#define PORT86CR	0xe6050056
+#define PORT87CR	0xe6050057
+#define PORT88CR	0xe6050058
+#define PORT89CR	0xe6050059
+#define PORT90CR	0xe605005a
+#define PORT91CR	0xe605005b
+#define PORT92CR	0xe605005c
+#define PORT99CR	0xe6050063
+#define PORT185CR	0xe60520b9
+#define PORT186CR	0xe60520ba
+#define PORT187CR	0xe60520bb
+#define PORT188CR	0xe60520bc
+
+#define SMSTPCR3	0xe615013c
+
+/* SH7372 specific MMCIF loader
+ *
+ * loads the zImage from an MMC card starting from block 1.
+ *
+ * The image must be start with a vrl4 header and
+ * the zImage must start at offset 512 of the image. That is,
+ * at block 2 (=byte 1024) on the media
+ *
+ * Use the following line to write the vrl4 formated zImage
+ * 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)
+{
+	/* 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);
+
+	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+
+	/* Initialise MMC
+	 * registers: PORT84CR-PORT92CR
+	 *            (MMCD0_0-MMCD0_7,MMCCMD0 Control)
+	 * value: 0x04 - select function 4
+	 */
+	 __raw_writeb(0x04, PORT84CR);
+	 __raw_writeb(0x04, PORT85CR);
+	 __raw_writeb(0x04, PORT86CR);
+	 __raw_writeb(0x04, PORT87CR);
+	 __raw_writeb(0x04, PORT88CR);
+	 __raw_writeb(0x04, PORT89CR);
+	 __raw_writeb(0x04, PORT90CR);
+	 __raw_writeb(0x04, PORT91CR);
+	 __raw_writeb(0x04, PORT92CR);
+
+	/* Initialise MMC
+	 * registers: PORT99CR (MMCCLK0 Control)
+	 * value: 0x10 | 0x04 - enable output | select function 4
+	 */
+	__raw_writeb(0x14, PORT99CR);
+
+	/* Enable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+
+	/* setup MMCIF hardware */
+	sh_mmcif_boot_init(MMCIF_BASE);
+
+	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+
+	/* load kernel via MMCIF interface */
+	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is at block 2 */
+			      (len + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS, buf);
+
+
+	/* Disable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+}
Index: linux-2.6-ap4/arch/arm/boot/compressed/Makefile
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/Makefile	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/Makefile	2010-12-06 09:11:42.000000000 +0900
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_SHMOBILE),y)
 OBJS		+= head-shmobile.o
 endif
 
+ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
+ifeq ($(CONFIG_ARCH_SH7372),y)
+OBJS		+= mmcif-sh7372.o
+endif
+endif
+
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:11:42.000000000 +0900
@@ -18,14 +18,33 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
-#ifdef CONFIG_ZBOOT_ROM
+#if defined(CONFIG_ZBOOT_ROM) || defined(CONFIG_ZBOOT_ROM_MMCIF)
 
 	.section	".start", "ax"
 
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-	b	1f
+	/* Load image from MMC */
+	adr	sp, __tmp_stack
+	add	sp, sp, #128
+	ldr	r0, __image_start
+	ldr	r1, __image_end
+	subs	r1, r1, r0
+	ldr	r0, __load_base
+	mov	lr, pc
+	b	mmcif_loader
+
+	/* Jump to loaded code */
+	ldr	r0, __loaded
+	ldr	r1, __image_start
+	sub	r0, r0, r1
+	ldr	r1, __load_base
+	add	pc, r0, r1
+
+	.align
+__tmp_stack:
+	.space	128
 __atags:@ tag #1
 	.long	12			@ tag->hdr.size = tag_size(tag_core);
 	.long	0x54410001		@ tag->hdr.tag = ATAG_CORE;
@@ -40,14 +59,19 @@ __atags:@ tag #1
 	@ tag #3
 	.long	0			@ tag->hdr.size = 0
 	.long	0			@ tag->hdr.tag = ATAG_NONE;
-1:
+__mach_type:
+	.long	MACH_TYPE
+__image_start:
+	.long	_start
+__image_end:
+	.long	_got_end
+__load_base:
+	.long	CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
+__loaded:
+	.long	__loaded
 
 	/* Set board ID necessary for boot */
-	ldr	r7, 1f				@ Set machine type register
+	ldr	r7, __mach_type			@ Set machine type register
 	adr	r8, __atags			@ Set atag register
-	b	2f
 
-1 :	.long MACH_TYPE
-2 :
-
-#endif /* CONFIG_ZBOOT_ROM */
+#endif /* CONFIG_ZBOOT_ROM || CONFIG_ZBOOT_ROM_MMCIF */
Index: linux-2.6-ap4/arch/arm/Kconfig
===================================================================
--- linux-2.6-ap4.orig/arch/arm/Kconfig	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/Kconfig	2010-12-06 09:11:42.000000000 +0900
@@ -1587,6 +1587,18 @@ 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.
 
+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.
+
 config CMDLINE
 	string "Default kernel command string"
 	default ""
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,12 @@
+#ifndef MMCIF_AP4EB_H
+#define MMCIF_AP4EB_H
+
+#define PORTR191_160DR 0xe6056014
+
+static void mmcif_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMCIF_AP4EB_H */
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,16 @@
+#ifndef MMCIF_H
+#define MMCIF_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmcif-ap4eb.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMCIF_H */
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+	rm -f *.o $(BIN)
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,167 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Magnus Damm
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *	  dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+	uint32_t magic1;
+	uint32_t reserved1;
+	uint32_t magic2;
+	uint32_t reserved2;
+	uint16_t copy_size;
+	uint16_t boot_options;
+	uint32_t reserved3;
+	uint32_t start_address;
+	uint32_t reserved4;
+	uint32_t reserved5;
+	char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)					\
+	struct hdr (h) = {				\
+		.magic1 =	0xea000000,		\
+		.reserved1 =	0x56,			\
+		.magic2 =	0xe59ff008,		\
+		.reserved3 =	0x1 }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS	9
+#define ALIGN		(1 << ALIGN_BITS)
+
+#define START_BASE	0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 40 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define	MAX_BOOT_PROG_LEN (40 * 512)
+
+#define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = read(fd, buf + offset, count - offset);
+		if (!l)
+			break;
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("read");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = write(fd, buf + offset, count - offset);
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("write");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+	size_t i = len;
+
+	while (i--) {
+		const char x = 0;
+		if (do_write(fd, &x, 1) < 0)
+			return -1;
+	}
+
+	return len;
+}
+
+int main(void)
+{
+	DECLARE_HDR(hdr);
+	char boot_program[MAX_BOOT_PROG_LEN];
+	size_t aligned_hdr_len, alligned_prog_len;
+	ssize_t prog_len;
+
+	prog_len = do_read(0, boot_program, sizeof(boot_program));
+	if (prog_len <= 0)
+		return -1;
+
+	aligned_hdr_len = ROUND_UP(sizeof(hdr));
+	hdr.start_address = START_BASE + aligned_hdr_len;
+	alligned_prog_len = ROUND_UP(prog_len);
+	hdr.copy_size = aligned_hdr_len + alligned_prog_len;
+
+	if (do_write(1, &hdr, sizeof(hdr)) < 0)
+		return -1;
+	if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+		return -1;
+
+	if (do_write(1, boot_program, prog_len) < 0)
+		return 1;
+
+	/* Write out the rest of the kernel */
+	while (1) {
+		prog_len = do_read(0, boot_program, sizeof(boot_program));
+		if (prog_len < 0)
+			return 1;
+		if (prog_len == 0)
+			break;
+		if (do_write(1, boot_program, prog_len) < 0)
+			return 1;
+	}
+
+	return 0;
+}
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt	2010-12-06 09:11:49.000000000 +0900
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF 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 AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card at sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

An embedded and charset-unspecified text was scrubbed...
Name: load-kernel-2.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20101206/9a4eeac5/attachment.ksh>

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
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: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
SuperH Mobile ARM" which has been merged into the devel branch
of Russell King's linux-2.6-arm tree.

Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,99 @@
+/*
+ * sh7372 MMCIF loader
+ *
+ * Copyright (C) 2010 Magnus Damm
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/mmc/sh_mmcif.h>
+#include <mach/mmcif.h>
+
+#define MMCIF_BASE      (void __iomem *)0xe6bd0000
+
+#define PORT84CR	0xe6050054
+#define PORT85CR	0xe6050055
+#define PORT86CR	0xe6050056
+#define PORT87CR	0xe6050057
+#define PORT88CR	0xe6050058
+#define PORT89CR	0xe6050059
+#define PORT90CR	0xe605005a
+#define PORT91CR	0xe605005b
+#define PORT92CR	0xe605005c
+#define PORT99CR	0xe6050063
+#define PORT185CR	0xe60520b9
+#define PORT186CR	0xe60520ba
+#define PORT187CR	0xe60520bb
+#define PORT188CR	0xe60520bc
+
+#define SMSTPCR3	0xe615013c
+
+/* SH7372 specific MMCIF loader
+ *
+ * loads the zImage from an MMC card starting from block 1.
+ *
+ * The image must be start with a vrl4 header and
+ * the zImage must start at offset 512 of the image. That is,
+ * at block 2 (=byte 1024) on the media
+ *
+ * Use the following line to write the vrl4 formated zImage
+ * to an MMC card
+ * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
+ */
+asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+{
+	/* 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);
+
+	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+
+	/* Initialise MMC
+	 * registers: PORT84CR-PORT92CR
+	 *            (MMCD0_0-MMCD0_7,MMCCMD0 Control)
+	 * value: 0x04 - select function 4
+	 */
+	 __raw_writeb(0x04, PORT84CR);
+	 __raw_writeb(0x04, PORT85CR);
+	 __raw_writeb(0x04, PORT86CR);
+	 __raw_writeb(0x04, PORT87CR);
+	 __raw_writeb(0x04, PORT88CR);
+	 __raw_writeb(0x04, PORT89CR);
+	 __raw_writeb(0x04, PORT90CR);
+	 __raw_writeb(0x04, PORT91CR);
+	 __raw_writeb(0x04, PORT92CR);
+
+	/* Initialise MMC
+	 * registers: PORT99CR (MMCCLK0 Control)
+	 * value: 0x10 | 0x04 - enable output | select function 4
+	 */
+	__raw_writeb(0x14, PORT99CR);
+
+	/* Enable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+
+	/* setup MMCIF hardware */
+	sh_mmcif_boot_init(MMCIF_BASE);
+
+	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+
+	/* load kernel via MMCIF interface */
+	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is at block 2 */
+			      (len + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS, buf);
+
+
+	/* Disable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+}
Index: linux-2.6-ap4/arch/arm/boot/compressed/Makefile
=================================--- linux-2.6-ap4.orig/arch/arm/boot/compressed/Makefile	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/Makefile	2010-12-06 09:11:42.000000000 +0900
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_SHMOBILE),y)
 OBJS		+= head-shmobile.o
 endif
 
+ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
+ifeq ($(CONFIG_ARCH_SH7372),y)
+OBJS		+= mmcif-sh7372.o
+endif
+endif
+
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
=================================--- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:11:42.000000000 +0900
@@ -18,14 +18,33 @@
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  */
 
-#ifdef CONFIG_ZBOOT_ROM
+#if defined(CONFIG_ZBOOT_ROM) || defined(CONFIG_ZBOOT_ROM_MMCIF)
 
 	.section	".start", "ax"
 
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
-	b	1f
+	/* Load image from MMC */
+	adr	sp, __tmp_stack
+	add	sp, sp, #128
+	ldr	r0, __image_start
+	ldr	r1, __image_end
+	subs	r1, r1, r0
+	ldr	r0, __load_base
+	mov	lr, pc
+	b	mmcif_loader
+
+	/* Jump to loaded code */
+	ldr	r0, __loaded
+	ldr	r1, __image_start
+	sub	r0, r0, r1
+	ldr	r1, __load_base
+	add	pc, r0, r1
+
+	.align
+__tmp_stack:
+	.space	128
 __atags:@ tag #1
 	.long	12			@ tag->hdr.size = tag_size(tag_core);
 	.long	0x54410001		@ tag->hdr.tag = ATAG_CORE;
@@ -40,14 +59,19 @@ __atags:@ tag #1
 	@ tag #3
 	.long	0			@ tag->hdr.size = 0
 	.long	0			@ tag->hdr.tag = ATAG_NONE;
-1:
+__mach_type:
+	.long	MACH_TYPE
+__image_start:
+	.long	_start
+__image_end:
+	.long	_got_end
+__load_base:
+	.long	CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
+__loaded:
+	.long	__loaded
 
 	/* Set board ID necessary for boot */
-	ldr	r7, 1f				@ Set machine type register
+	ldr	r7, __mach_type			@ Set machine type register
 	adr	r8, __atags			@ Set atag register
-	b	2f
 
-1 :	.long MACH_TYPE
-2 :
-
-#endif /* CONFIG_ZBOOT_ROM */
+#endif /* CONFIG_ZBOOT_ROM || CONFIG_ZBOOT_ROM_MMCIF */
Index: linux-2.6-ap4/arch/arm/Kconfig
=================================--- linux-2.6-ap4.orig/arch/arm/Kconfig	2010-12-06 09:11:35.000000000 +0900
+++ linux-2.6-ap4/arch/arm/Kconfig	2010-12-06 09:11:42.000000000 +0900
@@ -1587,6 +1587,18 @@ 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.
 
+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.
+
 config CMDLINE
 	string "Default kernel command string"
 	default ""
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,12 @@
+#ifndef MMCIF_AP4EB_H
+#define MMCIF_AP4EB_H
+
+#define PORTR191_160DR 0xe6056014
+
+static void mmcif_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMCIF_AP4EB_H */
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,16 @@
+#ifndef MMCIF_H
+#define MMCIF_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmcif-ap4eb.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMCIF_H */
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+	rm -f *.o $(BIN)
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c	2010-12-06 09:11:42.000000000 +0900
@@ -0,0 +1,167 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Magnus Damm
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *	  dd if=out of=/dev/sdx bsQ2 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+	uint32_t magic1;
+	uint32_t reserved1;
+	uint32_t magic2;
+	uint32_t reserved2;
+	uint16_t copy_size;
+	uint16_t boot_options;
+	uint32_t reserved3;
+	uint32_t start_address;
+	uint32_t reserved4;
+	uint32_t reserved5;
+	char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)					\
+	struct hdr (h) = {				\
+		.magic1 =	0xea000000,		\
+		.reserved1 =	0x56,			\
+		.magic2 =	0xe59ff008,		\
+		.reserved3 =	0x1 }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS	9
+#define ALIGN		(1 << ALIGN_BITS)
+
+#define START_BASE	0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 40 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define	MAX_BOOT_PROG_LEN (40 * 512)
+
+#define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = read(fd, buf + offset, count - offset);
+		if (!l)
+			break;
+		if (l < 0) {
+			if (errno = EAGAIN || errno = EWOULDBLOCK)
+				continue;
+			perror("read");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = write(fd, buf + offset, count - offset);
+		if (l < 0) {
+			if (errno = EAGAIN || errno = EWOULDBLOCK)
+				continue;
+			perror("write");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+	size_t i = len;
+
+	while (i--) {
+		const char x = 0;
+		if (do_write(fd, &x, 1) < 0)
+			return -1;
+	}
+
+	return len;
+}
+
+int main(void)
+{
+	DECLARE_HDR(hdr);
+	char boot_program[MAX_BOOT_PROG_LEN];
+	size_t aligned_hdr_len, alligned_prog_len;
+	ssize_t prog_len;
+
+	prog_len = do_read(0, boot_program, sizeof(boot_program));
+	if (prog_len <= 0)
+		return -1;
+
+	aligned_hdr_len = ROUND_UP(sizeof(hdr));
+	hdr.start_address = START_BASE + aligned_hdr_len;
+	alligned_prog_len = ROUND_UP(prog_len);
+	hdr.copy_size = aligned_hdr_len + alligned_prog_len;
+
+	if (do_write(1, &hdr, sizeof(hdr)) < 0)
+		return -1;
+	if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+		return -1;
+
+	if (do_write(1, boot_program, prog_len) < 0)
+		return 1;
+
+	/* Write out the rest of the kernel */
+	while (1) {
+		prog_len = do_read(0, boot_program, sizeof(boot_program));
+		if (prog_len < 0)
+			return 1;
+		if (prog_len = 0)
+			break;
+		if (do_write(1, boot_program, prog_len) < 0)
+			return 1;
+	}
+
+	return 0;
+}
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt	2010-12-06 09:11:49.000000000 +0900
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF 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 AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card at sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bsQ2 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 09:12:46AM +0900, Simon Horman wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> --- 
> 
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.

This patch also depends on the previous two patches in this series.

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 09:12:46AM +0900, Simon Horman wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> --- 
> 
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.

This patch also depends on the previous two patches in this series.

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH

[Simon Horman]

On Mon, Dec 06, 2010 at 09:12:46AM +0900, Simon Horman wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> 
> --- 
> 
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.

This patch also depends on the previous two patches in this series.

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Magnus Damm]

Hi Simon,

Thanks for your work on this!

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.
>
> Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> ===================================================================
> --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,99 @@
> +/*
> + * sh7372 MMCIF loader
> + *
> + * Copyright (C) 2010 Magnus Damm
> + * Copyright (C) 2010 Simon Horman
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/mmc/sh_mmcif.h>
> +#include <mach/mmcif.h>
> +
> +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> +
> +#define PORT84CR       0xe6050054
> +#define PORT85CR       0xe6050055
> +#define PORT86CR       0xe6050056
> +#define PORT87CR       0xe6050057
> +#define PORT88CR       0xe6050058
> +#define PORT89CR       0xe6050059
> +#define PORT90CR       0xe605005a
> +#define PORT91CR       0xe605005b
> +#define PORT92CR       0xe605005c
> +#define PORT99CR       0xe6050063
> +#define PORT185CR      0xe60520b9
> +#define PORT186CR      0xe60520ba
> +#define PORT187CR      0xe60520bb
> +#define PORT188CR      0xe60520bc
> +
> +#define SMSTPCR3       0xe615013c
> +
> +/* SH7372 specific MMCIF loader
> + *
> + * loads the zImage from an MMC card starting from block 1.
> + *
> + * The image must be start with a vrl4 header and
> + * the zImage must start at offset 512 of the image. That is,
> + * at block 2 (=byte 1024) on the media
> + *
> + * Use the following line to write the vrl4 formated zImage
> + * 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)
> +{
> +       /* 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);

Aren't these LEDs a board-specific property?

I believe the rest of the code is common across multiple boards, so
making it fully sharable would be nice.

Please break out the board-specific somehow, perhaps into
mmcif_update_progress().

> Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> ===================================================================
> --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> @@ -40,14 +59,19 @@ __atags:@ tag #1
>        @ tag #3
>        .long   0                       @ tag->hdr.size = 0
>        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> -1:
> +__mach_type:
> +       .long   MACH_TYPE
> +__image_start:
> +       .long   _start
> +__image_end:
> +       .long   _got_end
> +__load_base:
> +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM

Just curious, where does these 32Mb come from?

Say that a board with be equipped with less than 32Mb, how is that handled?

> Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> ===================================================================
> --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c    2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,167 @@
> +/*
> + * vrl4 format generator
> + *
> + * Copyright (C) 2010 Magnus Damm
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */

That's sweet, but I don't think I've got anything to do with this
portion of the code. =)

Apart from those minor points it all looks very good IMO!

/ magnus

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Magnus Damm]

Hi Simon,

Thanks for your work on this!

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.
>
> Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> ===================================================================
> --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c ? ? ? 2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,99 @@
> +/*
> + * sh7372 MMCIF loader
> + *
> + * Copyright (C) 2010 Magnus Damm
> + * Copyright (C) 2010 Simon Horman
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. ?See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/mmc/sh_mmcif.h>
> +#include <mach/mmcif.h>
> +
> +#define MMCIF_BASE ? ? ?(void __iomem *)0xe6bd0000
> +
> +#define PORT84CR ? ? ? 0xe6050054
> +#define PORT85CR ? ? ? 0xe6050055
> +#define PORT86CR ? ? ? 0xe6050056
> +#define PORT87CR ? ? ? 0xe6050057
> +#define PORT88CR ? ? ? 0xe6050058
> +#define PORT89CR ? ? ? 0xe6050059
> +#define PORT90CR ? ? ? 0xe605005a
> +#define PORT91CR ? ? ? 0xe605005b
> +#define PORT92CR ? ? ? 0xe605005c
> +#define PORT99CR ? ? ? 0xe6050063
> +#define PORT185CR ? ? ?0xe60520b9
> +#define PORT186CR ? ? ?0xe60520ba
> +#define PORT187CR ? ? ?0xe60520bb
> +#define PORT188CR ? ? ?0xe60520bc
> +
> +#define SMSTPCR3 ? ? ? 0xe615013c
> +
> +/* SH7372 specific MMCIF loader
> + *
> + * loads the zImage from an MMC card starting from block 1.
> + *
> + * The image must be start with a vrl4 header and
> + * the zImage must start at offset 512 of the image. That is,
> + * at block 2 (=byte 1024) on the media
> + *
> + * Use the following line to write the vrl4 formated zImage
> + * 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)
> +{
> + ? ? ? /* 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);

Aren't these LEDs a board-specific property?

I believe the rest of the code is common across multiple boards, so
making it fully sharable would be nice.

Please break out the board-specific somehow, perhaps into
mmcif_update_progress().

> Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> ===================================================================
> --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S ? ? ?2010-12-06 09:11:42.000000000 +0900
> @@ -40,14 +59,19 @@ __atags:@ tag #1
> ? ? ? ?@ tag #3
> ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.size = 0
> ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.tag = ATAG_NONE;
> -1:
> +__mach_type:
> + ? ? ? .long ? MACH_TYPE
> +__image_start:
> + ? ? ? .long ? _start
> +__image_end:
> + ? ? ? .long ? _got_end
> +__load_base:
> + ? ? ? .long ? CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM

Just curious, where does these 32Mb come from?

Say that a board with be equipped with less than 32Mb, how is that handled?

> Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> ===================================================================
> --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c ? ?2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,167 @@
> +/*
> + * vrl4 format generator
> + *
> + * Copyright (C) 2010 Magnus Damm
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. ?See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */

That's sweet, but I don't think I've got anything to do with this
portion of the code. =)

Apart from those minor points it all looks very good IMO!

/ magnus

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH

[Magnus Damm]

Hi Simon,

Thanks for your work on this!

On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> This allows a ROM-able zImage to be written to MMC and
> for SuperH Mobile ARM to boot directly from the MMCIF
> 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: Magnus Damm <magnus.damm@gmail.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
>
> ---
>
> This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> SuperH Mobile ARM" which has been merged into the devel branch
> of Russell King's linux-2.6-arm tree.
>
> Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> =================================> --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,99 @@
> +/*
> + * sh7372 MMCIF loader
> + *
> + * Copyright (C) 2010 Magnus Damm
> + * Copyright (C) 2010 Simon Horman
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#include <linux/mmc/sh_mmcif.h>
> +#include <mach/mmcif.h>
> +
> +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> +
> +#define PORT84CR       0xe6050054
> +#define PORT85CR       0xe6050055
> +#define PORT86CR       0xe6050056
> +#define PORT87CR       0xe6050057
> +#define PORT88CR       0xe6050058
> +#define PORT89CR       0xe6050059
> +#define PORT90CR       0xe605005a
> +#define PORT91CR       0xe605005b
> +#define PORT92CR       0xe605005c
> +#define PORT99CR       0xe6050063
> +#define PORT185CR      0xe60520b9
> +#define PORT186CR      0xe60520ba
> +#define PORT187CR      0xe60520bb
> +#define PORT188CR      0xe60520bc
> +
> +#define SMSTPCR3       0xe615013c
> +
> +/* SH7372 specific MMCIF loader
> + *
> + * loads the zImage from an MMC card starting from block 1.
> + *
> + * The image must be start with a vrl4 header and
> + * the zImage must start at offset 512 of the image. That is,
> + * at block 2 (=byte 1024) on the media
> + *
> + * Use the following line to write the vrl4 formated zImage
> + * to an MMC card
> + * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
> + */
> +asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
> +{
> +       /* 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);

Aren't these LEDs a board-specific property?

I believe the rest of the code is common across multiple boards, so
making it fully sharable would be nice.

Please break out the board-specific somehow, perhaps into
mmcif_update_progress().

> Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> =================================> --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> @@ -40,14 +59,19 @@ __atags:@ tag #1
>        @ tag #3
>        .long   0                       @ tag->hdr.size = 0
>        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> -1:
> +__mach_type:
> +       .long   MACH_TYPE
> +__image_start:
> +       .long   _start
> +__image_end:
> +       .long   _got_end
> +__load_base:
> +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM

Just curious, where does these 32Mb come from?

Say that a board with be equipped with less than 32Mb, how is that handled?

> Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> =================================> --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c    2010-12-06 09:11:42.000000000 +0900
> @@ -0,0 +1,167 @@
> +/*
> + * vrl4 format generator
> + *
> + * Copyright (C) 2010 Magnus Damm
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */

That's sweet, but I don't think I've got anything to do with this
portion of the code. =)

Apart from those minor points it all looks very good IMO!

/ magnus

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> Thanks for your work on this!
> 
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > This allows a ROM-able zImage to be written to MMC and
> > for SuperH Mobile ARM to boot directly from the MMCIF
> > 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: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> > SuperH Mobile ARM" which has been merged into the devel branch
> > of Russell King's linux-2.6-arm tree.
> >
> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> > ===================================================================
> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,99 @@
> > +/*
> > + * sh7372 MMCIF loader
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + * Copyright (C) 2010 Simon Horman
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> > +
> > +#include <linux/mmc/sh_mmcif.h>
> > +#include <mach/mmcif.h>
> > +
> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> > +
> > +#define PORT84CR       0xe6050054
> > +#define PORT85CR       0xe6050055
> > +#define PORT86CR       0xe6050056
> > +#define PORT87CR       0xe6050057
> > +#define PORT88CR       0xe6050058
> > +#define PORT89CR       0xe6050059
> > +#define PORT90CR       0xe605005a
> > +#define PORT91CR       0xe605005b
> > +#define PORT92CR       0xe605005c
> > +#define PORT99CR       0xe6050063
> > +#define PORT185CR      0xe60520b9
> > +#define PORT186CR      0xe60520ba
> > +#define PORT187CR      0xe60520bb
> > +#define PORT188CR      0xe60520bc
> > +
> > +#define SMSTPCR3       0xe615013c
> > +
> > +/* SH7372 specific MMCIF loader
> > + *
> > + * loads the zImage from an MMC card starting from block 1.
> > + *
> > + * The image must be start with a vrl4 header and
> > + * the zImage must start at offset 512 of the image. That is,
> > + * at block 2 (=byte 1024) on the media
> > + *
> > + * Use the following line to write the vrl4 formated zImage
> > + * 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)
> > +{
> > +       /* 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);
> 
> Aren't these LEDs a board-specific property?
> 
> I believe the rest of the code is common across multiple boards, so
> making it fully sharable would be nice.
> 
> Please break out the board-specific somehow, perhaps into
> mmcif_update_progress().

Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
Or remove mmcif_update_progress() all together?

> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> > ===================================================================
> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> >        @ tag #3
> >        .long   0                       @ tag->hdr.size = 0
> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> > -1:
> > +__mach_type:
> > +       .long   MACH_TYPE
> > +__image_start:
> > +       .long   _start
> > +__image_end:
> > +       .long   _got_end
> > +__load_base:
> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> 
> Just curious, where does these 32Mb come from?

IMHO Its fairly arbitrary where the zImage is copied to.
I chose 32Mb as it is the same place that uboot puts images.

> Say that a board with be equipped with less than 32Mb, how is that handled?

It isn't.

An alternate approach might be to just place it at the end of the
destination, which can be approximated using 4 * the compressed image size.
The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.

I'm open to other ideas about where to copy the zImage to.

> > Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> > ===================================================================
> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c    2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,167 @@
> > +/*
> > + * vrl4 format generator
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> 
> That's sweet, but I don't think I've got anything to do with this
> portion of the code. =)

Sorry, I had both of our names there from text copied from elsewhere
and deleted the wrong one.

> Apart from those minor points it all looks very good IMO!

Thanks!

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> Thanks for your work on this!
> 
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > This allows a ROM-able zImage to be written to MMC and
> > for SuperH Mobile ARM to boot directly from the MMCIF
> > 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: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> > SuperH Mobile ARM" which has been merged into the devel branch
> > of Russell King's linux-2.6-arm tree.
> >
> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> > ===================================================================
> > --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c ? ? ? 2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,99 @@
> > +/*
> > + * sh7372 MMCIF loader
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + * Copyright (C) 2010 Simon Horman
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License. ?See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> > +
> > +#include <linux/mmc/sh_mmcif.h>
> > +#include <mach/mmcif.h>
> > +
> > +#define MMCIF_BASE ? ? ?(void __iomem *)0xe6bd0000
> > +
> > +#define PORT84CR ? ? ? 0xe6050054
> > +#define PORT85CR ? ? ? 0xe6050055
> > +#define PORT86CR ? ? ? 0xe6050056
> > +#define PORT87CR ? ? ? 0xe6050057
> > +#define PORT88CR ? ? ? 0xe6050058
> > +#define PORT89CR ? ? ? 0xe6050059
> > +#define PORT90CR ? ? ? 0xe605005a
> > +#define PORT91CR ? ? ? 0xe605005b
> > +#define PORT92CR ? ? ? 0xe605005c
> > +#define PORT99CR ? ? ? 0xe6050063
> > +#define PORT185CR ? ? ?0xe60520b9
> > +#define PORT186CR ? ? ?0xe60520ba
> > +#define PORT187CR ? ? ?0xe60520bb
> > +#define PORT188CR ? ? ?0xe60520bc
> > +
> > +#define SMSTPCR3 ? ? ? 0xe615013c
> > +
> > +/* SH7372 specific MMCIF loader
> > + *
> > + * loads the zImage from an MMC card starting from block 1.
> > + *
> > + * The image must be start with a vrl4 header and
> > + * the zImage must start at offset 512 of the image. That is,
> > + * at block 2 (=byte 1024) on the media
> > + *
> > + * Use the following line to write the vrl4 formated zImage
> > + * 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)
> > +{
> > + ? ? ? /* 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);
> 
> Aren't these LEDs a board-specific property?
> 
> I believe the rest of the code is common across multiple boards, so
> making it fully sharable would be nice.
> 
> Please break out the board-specific somehow, perhaps into
> mmcif_update_progress().

Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
Or remove mmcif_update_progress() all together?

> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> > ===================================================================
> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S ? ? ?2010-12-06 09:11:42.000000000 +0900
> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> > ? ? ? ?@ tag #3
> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.size = 0
> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.tag = ATAG_NONE;
> > -1:
> > +__mach_type:
> > + ? ? ? .long ? MACH_TYPE
> > +__image_start:
> > + ? ? ? .long ? _start
> > +__image_end:
> > + ? ? ? .long ? _got_end
> > +__load_base:
> > + ? ? ? .long ? CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> 
> Just curious, where does these 32Mb come from?

IMHO Its fairly arbitrary where the zImage is copied to.
I chose 32Mb as it is the same place that uboot puts images.

> Say that a board with be equipped with less than 32Mb, how is that handled?

It isn't.

An alternate approach might be to just place it at the end of the
destination, which can be approximated using 4 * the compressed image size.
The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.

I'm open to other ideas about where to copy the zImage to.

> > Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> > ===================================================================
> > --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c ? ?2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,167 @@
> > +/*
> > + * vrl4 format generator
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License. ?See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> 
> That's sweet, but I don't think I've got anything to do with this
> portion of the code. =)

Sorry, I had both of our names there from text copied from elsewhere
and deleted the wrong one.

> Apart from those minor points it all looks very good IMO!

Thanks!

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH

[Simon Horman]

On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> Thanks for your work on this!
> 
> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> > This allows a ROM-able zImage to be written to MMC and
> > for SuperH Mobile ARM to boot directly from the MMCIF
> > 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: Magnus Damm <magnus.damm@gmail.com>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > ---
> >
> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> > SuperH Mobile ARM" which has been merged into the devel branch
> > of Russell King's linux-2.6-arm tree.
> >
> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> > =================================> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,99 @@
> > +/*
> > + * sh7372 MMCIF loader
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + * Copyright (C) 2010 Simon Horman
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> > +
> > +#include <linux/mmc/sh_mmcif.h>
> > +#include <mach/mmcif.h>
> > +
> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> > +
> > +#define PORT84CR       0xe6050054
> > +#define PORT85CR       0xe6050055
> > +#define PORT86CR       0xe6050056
> > +#define PORT87CR       0xe6050057
> > +#define PORT88CR       0xe6050058
> > +#define PORT89CR       0xe6050059
> > +#define PORT90CR       0xe605005a
> > +#define PORT91CR       0xe605005b
> > +#define PORT92CR       0xe605005c
> > +#define PORT99CR       0xe6050063
> > +#define PORT185CR      0xe60520b9
> > +#define PORT186CR      0xe60520ba
> > +#define PORT187CR      0xe60520bb
> > +#define PORT188CR      0xe60520bc
> > +
> > +#define SMSTPCR3       0xe615013c
> > +
> > +/* SH7372 specific MMCIF loader
> > + *
> > + * loads the zImage from an MMC card starting from block 1.
> > + *
> > + * The image must be start with a vrl4 header and
> > + * the zImage must start at offset 512 of the image. That is,
> > + * at block 2 (=byte 1024) on the media
> > + *
> > + * Use the following line to write the vrl4 formated zImage
> > + * to an MMC card
> > + * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
> > + */
> > +asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
> > +{
> > +       /* 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);
> 
> Aren't these LEDs a board-specific property?
> 
> I believe the rest of the code is common across multiple boards, so
> making it fully sharable would be nice.
> 
> Please break out the board-specific somehow, perhaps into
> mmcif_update_progress().

Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
Or remove mmcif_update_progress() all together?

> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> > =================================> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> >        @ tag #3
> >        .long   0                       @ tag->hdr.size = 0
> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> > -1:
> > +__mach_type:
> > +       .long   MACH_TYPE
> > +__image_start:
> > +       .long   _start
> > +__image_end:
> > +       .long   _got_end
> > +__load_base:
> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> 
> Just curious, where does these 32Mb come from?

IMHO Its fairly arbitrary where the zImage is copied to.
I chose 32Mb as it is the same place that uboot puts images.

> Say that a board with be equipped with less than 32Mb, how is that handled?

It isn't.

An alternate approach might be to just place it at the end of the
destination, which can be approximated using 4 * the compressed image size.
The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.

I'm open to other ideas about where to copy the zImage to.

> > Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
> > =================================> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> > +++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c    2010-12-06 09:11:42.000000000 +0900
> > @@ -0,0 +1,167 @@
> > +/*
> > + * vrl4 format generator
> > + *
> > + * Copyright (C) 2010 Magnus Damm
> > + *
> > + * This file is subject to the terms and conditions of the GNU General Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + */
> 
> That's sweet, but I don't think I've got anything to do with this
> portion of the code. =)

Sorry, I had both of our names there from text copied from elsewhere
and deleted the wrong one.

> Apart from those minor points it all looks very good IMO!

Thanks!

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > This allows a ROM-able zImage to be written to MMC and
>> > for SuperH Mobile ARM to boot directly from the MMCIF
>> > 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: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>> >
>> > ---
>> >
>> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
>> > SuperH Mobile ARM" which has been merged into the devel branch
>> > of Russell King's linux-2.6-arm tree.
>> >
>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
>> > ===================================================================
>> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
>> > @@ -0,0 +1,99 @@
>> > +/*
>> > + * sh7372 MMCIF loader
>> > + *
>> > + * Copyright (C) 2010 Magnus Damm
>> > + * Copyright (C) 2010 Simon Horman
>> > + *
>> > + * This file is subject to the terms and conditions of the GNU General Public
>> > + * License.  See the file "COPYING" in the main directory of this archive
>> > + * for more details.
>> > + */
>> > +
>> > +#include <linux/mmc/sh_mmcif.h>
>> > +#include <mach/mmcif.h>
>> > +
>> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
>> > +
>> > +#define PORT84CR       0xe6050054
>> > +#define PORT85CR       0xe6050055
>> > +#define PORT86CR       0xe6050056
>> > +#define PORT87CR       0xe6050057
>> > +#define PORT88CR       0xe6050058
>> > +#define PORT89CR       0xe6050059
>> > +#define PORT90CR       0xe605005a
>> > +#define PORT91CR       0xe605005b
>> > +#define PORT92CR       0xe605005c
>> > +#define PORT99CR       0xe6050063
>> > +#define PORT185CR      0xe60520b9
>> > +#define PORT186CR      0xe60520ba
>> > +#define PORT187CR      0xe60520bb
>> > +#define PORT188CR      0xe60520bc
>> > +
>> > +#define SMSTPCR3       0xe615013c
>> > +
>> > +/* SH7372 specific MMCIF loader
>> > + *
>> > + * loads the zImage from an MMC card starting from block 1.
>> > + *
>> > + * The image must be start with a vrl4 header and
>> > + * the zImage must start at offset 512 of the image. That is,
>> > + * at block 2 (=byte 1024) on the media
>> > + *
>> > + * Use the following line to write the vrl4 formated zImage
>> > + * 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)
>> > +{
>> > +       /* 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);
>>
>> Aren't these LEDs a board-specific property?
>>
>> I believe the rest of the code is common across multiple boards, so
>> making it fully sharable would be nice.
>>
>> Please break out the board-specific somehow, perhaps into
>> mmcif_update_progress().
>
> Sure, perhaps we could just move this initialisation into head-ap4evb.txt?

Sounds good!

> Or remove mmcif_update_progress() all together?

Nah, I prefer to keep some kind of abstraction for the progress meter.

>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
>> > ===================================================================
>> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
>> > @@ -40,14 +59,19 @@ __atags:@ tag #1
>> >        @ tag #3
>> >        .long   0                       @ tag->hdr.size = 0
>> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
>> > -1:
>> > +__mach_type:
>> > +       .long   MACH_TYPE
>> > +__image_start:
>> > +       .long   _start
>> > +__image_end:
>> > +       .long   _got_end
>> > +__load_base:
>> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
>>
>> Just curious, where does these 32Mb come from?
>
> IMHO Its fairly arbitrary where the zImage is copied to.
> I chose 32Mb as it is the same place that uboot puts images.

That makes sense.

>> Say that a board with be equipped with less than 32Mb, how is that handled?
>
> It isn't.
>
> An alternate approach might be to just place it at the end of the
> destination, which can be approximated using 4 * the compressed image size.
> The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
>
> I'm open to other ideas about where to copy the zImage to.

What's stopping us from loading the kernel image from MMC straight to
CONFIG_MEMORY_START?

At least that's simple - but I suppose it isn't working right out of the box.

Judging by the code in arch/arm/boot/compressed/head.S it looks like
the zImage should be able to relocate itself.

Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
kernel is executing from flash or rom, which is true for our NOR flash
boot case, but is false when we're booting from MMC.

/ magnus

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > This allows a ROM-able zImage to be written to MMC and
>> > for SuperH Mobile ARM to boot directly from the MMCIF
>> > 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: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>> >
>> > ---
>> >
>> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
>> > SuperH Mobile ARM" which has been merged into the devel branch
>> > of Russell King's linux-2.6-arm tree.
>> >
>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
>> > ===================================================================
>> > --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c ? ? ? 2010-12-06 09:11:42.000000000 +0900
>> > @@ -0,0 +1,99 @@
>> > +/*
>> > + * sh7372 MMCIF loader
>> > + *
>> > + * Copyright (C) 2010 Magnus Damm
>> > + * Copyright (C) 2010 Simon Horman
>> > + *
>> > + * This file is subject to the terms and conditions of the GNU General Public
>> > + * License. ?See the file "COPYING" in the main directory of this archive
>> > + * for more details.
>> > + */
>> > +
>> > +#include <linux/mmc/sh_mmcif.h>
>> > +#include <mach/mmcif.h>
>> > +
>> > +#define MMCIF_BASE ? ? ?(void __iomem *)0xe6bd0000
>> > +
>> > +#define PORT84CR ? ? ? 0xe6050054
>> > +#define PORT85CR ? ? ? 0xe6050055
>> > +#define PORT86CR ? ? ? 0xe6050056
>> > +#define PORT87CR ? ? ? 0xe6050057
>> > +#define PORT88CR ? ? ? 0xe6050058
>> > +#define PORT89CR ? ? ? 0xe6050059
>> > +#define PORT90CR ? ? ? 0xe605005a
>> > +#define PORT91CR ? ? ? 0xe605005b
>> > +#define PORT92CR ? ? ? 0xe605005c
>> > +#define PORT99CR ? ? ? 0xe6050063
>> > +#define PORT185CR ? ? ?0xe60520b9
>> > +#define PORT186CR ? ? ?0xe60520ba
>> > +#define PORT187CR ? ? ?0xe60520bb
>> > +#define PORT188CR ? ? ?0xe60520bc
>> > +
>> > +#define SMSTPCR3 ? ? ? 0xe615013c
>> > +
>> > +/* SH7372 specific MMCIF loader
>> > + *
>> > + * loads the zImage from an MMC card starting from block 1.
>> > + *
>> > + * The image must be start with a vrl4 header and
>> > + * the zImage must start at offset 512 of the image. That is,
>> > + * at block 2 (=byte 1024) on the media
>> > + *
>> > + * Use the following line to write the vrl4 formated zImage
>> > + * 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)
>> > +{
>> > + ? ? ? /* 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);
>>
>> Aren't these LEDs a board-specific property?
>>
>> I believe the rest of the code is common across multiple boards, so
>> making it fully sharable would be nice.
>>
>> Please break out the board-specific somehow, perhaps into
>> mmcif_update_progress().
>
> Sure, perhaps we could just move this initialisation into head-ap4evb.txt?

Sounds good!

> Or remove mmcif_update_progress() all together?

Nah, I prefer to keep some kind of abstraction for the progress meter.

>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
>> > ===================================================================
>> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S ? ? ?2010-12-06 09:11:42.000000000 +0900
>> > @@ -40,14 +59,19 @@ __atags:@ tag #1
>> > ? ? ? ?@ tag #3
>> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.size = 0
>> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.tag = ATAG_NONE;
>> > -1:
>> > +__mach_type:
>> > + ? ? ? .long ? MACH_TYPE
>> > +__image_start:
>> > + ? ? ? .long ? _start
>> > +__image_end:
>> > + ? ? ? .long ? _got_end
>> > +__load_base:
>> > + ? ? ? .long ? CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
>>
>> Just curious, where does these 32Mb come from?
>
> IMHO Its fairly arbitrary where the zImage is copied to.
> I chose 32Mb as it is the same place that uboot puts images.

That makes sense.

>> Say that a board with be equipped with less than 32Mb, how is that handled?
>
> It isn't.
>
> An alternate approach might be to just place it at the end of the
> destination, which can be approximated using 4 * the compressed image size.
> The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
>
> I'm open to other ideas about where to copy the zImage to.

What's stopping us from loading the kernel image from MMC straight to
CONFIG_MEMORY_START?

At least that's simple - but I suppose it isn't working right out of the box.

Judging by the code in arch/arm/boot/compressed/head.S it looks like
the zImage should be able to relocate itself.

Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
kernel is executing from flash or rom, which is true for our NOR flash
boot case, but is false when we're booting from MMC.

/ magnus

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH

[Magnus Damm]

On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
>> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
>> > This allows a ROM-able zImage to be written to MMC and
>> > for SuperH Mobile ARM to boot directly from the MMCIF
>> > 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: Magnus Damm <magnus.damm@gmail.com>
>> > Signed-off-by: Simon Horman <horms@verge.net.au>
>> >
>> > ---
>> >
>> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
>> > SuperH Mobile ARM" which has been merged into the devel branch
>> > of Russell King's linux-2.6-arm tree.
>> >
>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
>> > =================================>> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
>> > @@ -0,0 +1,99 @@
>> > +/*
>> > + * sh7372 MMCIF loader
>> > + *
>> > + * Copyright (C) 2010 Magnus Damm
>> > + * Copyright (C) 2010 Simon Horman
>> > + *
>> > + * This file is subject to the terms and conditions of the GNU General Public
>> > + * License.  See the file "COPYING" in the main directory of this archive
>> > + * for more details.
>> > + */
>> > +
>> > +#include <linux/mmc/sh_mmcif.h>
>> > +#include <mach/mmcif.h>
>> > +
>> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
>> > +
>> > +#define PORT84CR       0xe6050054
>> > +#define PORT85CR       0xe6050055
>> > +#define PORT86CR       0xe6050056
>> > +#define PORT87CR       0xe6050057
>> > +#define PORT88CR       0xe6050058
>> > +#define PORT89CR       0xe6050059
>> > +#define PORT90CR       0xe605005a
>> > +#define PORT91CR       0xe605005b
>> > +#define PORT92CR       0xe605005c
>> > +#define PORT99CR       0xe6050063
>> > +#define PORT185CR      0xe60520b9
>> > +#define PORT186CR      0xe60520ba
>> > +#define PORT187CR      0xe60520bb
>> > +#define PORT188CR      0xe60520bc
>> > +
>> > +#define SMSTPCR3       0xe615013c
>> > +
>> > +/* SH7372 specific MMCIF loader
>> > + *
>> > + * loads the zImage from an MMC card starting from block 1.
>> > + *
>> > + * The image must be start with a vrl4 header and
>> > + * the zImage must start at offset 512 of the image. That is,
>> > + * at block 2 (=byte 1024) on the media
>> > + *
>> > + * Use the following line to write the vrl4 formated zImage
>> > + * to an MMC card
>> > + * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
>> > + */
>> > +asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
>> > +{
>> > +       /* 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);
>>
>> Aren't these LEDs a board-specific property?
>>
>> I believe the rest of the code is common across multiple boards, so
>> making it fully sharable would be nice.
>>
>> Please break out the board-specific somehow, perhaps into
>> mmcif_update_progress().
>
> Sure, perhaps we could just move this initialisation into head-ap4evb.txt?

Sounds good!

> Or remove mmcif_update_progress() all together?

Nah, I prefer to keep some kind of abstraction for the progress meter.

>> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
>> > =================================>> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
>> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
>> > @@ -40,14 +59,19 @@ __atags:@ tag #1
>> >        @ tag #3
>> >        .long   0                       @ tag->hdr.size = 0
>> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
>> > -1:
>> > +__mach_type:
>> > +       .long   MACH_TYPE
>> > +__image_start:
>> > +       .long   _start
>> > +__image_end:
>> > +       .long   _got_end
>> > +__load_base:
>> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
>>
>> Just curious, where does these 32Mb come from?
>
> IMHO Its fairly arbitrary where the zImage is copied to.
> I chose 32Mb as it is the same place that uboot puts images.

That makes sense.

>> Say that a board with be equipped with less than 32Mb, how is that handled?
>
> It isn't.
>
> An alternate approach might be to just place it at the end of the
> destination, which can be approximated using 4 * the compressed image size.
> The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
>
> I'm open to other ideas about where to copy the zImage to.

What's stopping us from loading the kernel image from MMC straight to
CONFIG_MEMORY_START?

At least that's simple - but I suppose it isn't working right out of the box.

Judging by the code in arch/arm/boot/compressed/head.S it looks like
the zImage should be able to relocate itself.

Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
kernel is executing from flash or rom, which is true for our NOR flash
boot case, but is false when we're booting from MMC.

/ magnus

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 10:33:40AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> >> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > This allows a ROM-able zImage to be written to MMC and
> >> > for SuperH Mobile ARM to boot directly from the MMCIF
> >> > 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: Magnus Damm <magnus.damm@gmail.com>
> >> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >> >
> >> > ---
> >> >
> >> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> >> > SuperH Mobile ARM" which has been merged into the devel branch
> >> > of Russell King's linux-2.6-arm tree.
> >> >
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> >> > ===================================================================
> >> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> >> > @@ -0,0 +1,99 @@
> >> > +/*
> >> > + * sh7372 MMCIF loader
> >> > + *
> >> > + * Copyright (C) 2010 Magnus Damm
> >> > + * Copyright (C) 2010 Simon Horman
> >> > + *
> >> > + * This file is subject to the terms and conditions of the GNU General Public
> >> > + * License.  See the file "COPYING" in the main directory of this archive
> >> > + * for more details.
> >> > + */
> >> > +
> >> > +#include <linux/mmc/sh_mmcif.h>
> >> > +#include <mach/mmcif.h>
> >> > +
> >> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> >> > +
> >> > +#define PORT84CR       0xe6050054
> >> > +#define PORT85CR       0xe6050055
> >> > +#define PORT86CR       0xe6050056
> >> > +#define PORT87CR       0xe6050057
> >> > +#define PORT88CR       0xe6050058
> >> > +#define PORT89CR       0xe6050059
> >> > +#define PORT90CR       0xe605005a
> >> > +#define PORT91CR       0xe605005b
> >> > +#define PORT92CR       0xe605005c
> >> > +#define PORT99CR       0xe6050063
> >> > +#define PORT185CR      0xe60520b9
> >> > +#define PORT186CR      0xe60520ba
> >> > +#define PORT187CR      0xe60520bb
> >> > +#define PORT188CR      0xe60520bc
> >> > +
> >> > +#define SMSTPCR3       0xe615013c
> >> > +
> >> > +/* SH7372 specific MMCIF loader
> >> > + *
> >> > + * loads the zImage from an MMC card starting from block 1.
> >> > + *
> >> > + * The image must be start with a vrl4 header and
> >> > + * the zImage must start at offset 512 of the image. That is,
> >> > + * at block 2 (=byte 1024) on the media
> >> > + *
> >> > + * Use the following line to write the vrl4 formated zImage
> >> > + * 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)
> >> > +{
> >> > +       /* 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);
> >>
> >> Aren't these LEDs a board-specific property?
> >>
> >> I believe the rest of the code is common across multiple boards, so
> >> making it fully sharable would be nice.
> >>
> >> Please break out the board-specific somehow, perhaps into
> >> mmcif_update_progress().
> >
> > Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
> 
> Sounds good!
> 
> > Or remove mmcif_update_progress() all together?
> 
> Nah, I prefer to keep some kind of abstraction for the progress meter.
> 
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> >> > ===================================================================
> >> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> >> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> >> >        @ tag #3
> >> >        .long   0                       @ tag->hdr.size = 0
> >> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> >> > -1:
> >> > +__mach_type:
> >> > +       .long   MACH_TYPE
> >> > +__image_start:
> >> > +       .long   _start
> >> > +__image_end:
> >> > +       .long   _got_end
> >> > +__load_base:
> >> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> >>
> >> Just curious, where does these 32Mb come from?
> >
> > IMHO Its fairly arbitrary where the zImage is copied to.
> > I chose 32Mb as it is the same place that uboot puts images.
> 
> That makes sense.
> 
> >> Say that a board with be equipped with less than 32Mb, how is that handled?
> >
> > It isn't.
> >
> > An alternate approach might be to just place it at the end of the
> > destination, which can be approximated using 4 * the compressed image size.
> > The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
> >
> > I'm open to other ideas about where to copy the zImage to.
> 
> What's stopping us from loading the kernel image from MMC straight to
> CONFIG_MEMORY_START?

Because what is expected in the end is an uncompressed
kernel at CONFIG_MEMORY_START + TEXT_OFFSET and the compressed
image won't fit between in TEXT_OFFSET bytes.

> At least that's simple - but I suppose it isn't working right out of the box.
> 
> Judging by the code in arch/arm/boot/compressed/head.S it looks like
> the zImage should be able to relocate itself.
> 
> Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
> arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
> boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
> kernel is executing from flash or rom, which is true for our NOR flash
> boot case, but is false when we're booting from MMC.

Could you be more specific about which bits of head.S you are looking at?

[patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

On Mon, Dec 06, 2010 at 10:33:40AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> >> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > This allows a ROM-able zImage to be written to MMC and
> >> > for SuperH Mobile ARM to boot directly from the MMCIF
> >> > 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: Magnus Damm <magnus.damm@gmail.com>
> >> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >> >
> >> > ---
> >> >
> >> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> >> > SuperH Mobile ARM" which has been merged into the devel branch
> >> > of Russell King's linux-2.6-arm tree.
> >> >
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> >> > ===================================================================
> >> > --- /dev/null ? 1970-01-01 00:00:00.000000000 +0000
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c ? ? ? 2010-12-06 09:11:42.000000000 +0900
> >> > @@ -0,0 +1,99 @@
> >> > +/*
> >> > + * sh7372 MMCIF loader
> >> > + *
> >> > + * Copyright (C) 2010 Magnus Damm
> >> > + * Copyright (C) 2010 Simon Horman
> >> > + *
> >> > + * This file is subject to the terms and conditions of the GNU General Public
> >> > + * License. ?See the file "COPYING" in the main directory of this archive
> >> > + * for more details.
> >> > + */
> >> > +
> >> > +#include <linux/mmc/sh_mmcif.h>
> >> > +#include <mach/mmcif.h>
> >> > +
> >> > +#define MMCIF_BASE ? ? ?(void __iomem *)0xe6bd0000
> >> > +
> >> > +#define PORT84CR ? ? ? 0xe6050054
> >> > +#define PORT85CR ? ? ? 0xe6050055
> >> > +#define PORT86CR ? ? ? 0xe6050056
> >> > +#define PORT87CR ? ? ? 0xe6050057
> >> > +#define PORT88CR ? ? ? 0xe6050058
> >> > +#define PORT89CR ? ? ? 0xe6050059
> >> > +#define PORT90CR ? ? ? 0xe605005a
> >> > +#define PORT91CR ? ? ? 0xe605005b
> >> > +#define PORT92CR ? ? ? 0xe605005c
> >> > +#define PORT99CR ? ? ? 0xe6050063
> >> > +#define PORT185CR ? ? ?0xe60520b9
> >> > +#define PORT186CR ? ? ?0xe60520ba
> >> > +#define PORT187CR ? ? ?0xe60520bb
> >> > +#define PORT188CR ? ? ?0xe60520bc
> >> > +
> >> > +#define SMSTPCR3 ? ? ? 0xe615013c
> >> > +
> >> > +/* SH7372 specific MMCIF loader
> >> > + *
> >> > + * loads the zImage from an MMC card starting from block 1.
> >> > + *
> >> > + * The image must be start with a vrl4 header and
> >> > + * the zImage must start at offset 512 of the image. That is,
> >> > + * at block 2 (=byte 1024) on the media
> >> > + *
> >> > + * Use the following line to write the vrl4 formated zImage
> >> > + * 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)
> >> > +{
> >> > + ? ? ? /* 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);
> >>
> >> Aren't these LEDs a board-specific property?
> >>
> >> I believe the rest of the code is common across multiple boards, so
> >> making it fully sharable would be nice.
> >>
> >> Please break out the board-specific somehow, perhaps into
> >> mmcif_update_progress().
> >
> > Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
> 
> Sounds good!
> 
> > Or remove mmcif_update_progress() all together?
> 
> Nah, I prefer to keep some kind of abstraction for the progress meter.
> 
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> >> > ===================================================================
> >> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S ? ? ?2010-12-06 09:11:42.000000000 +0900
> >> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> >> > ? ? ? ?@ tag #3
> >> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.size = 0
> >> > ? ? ? ?.long ? 0 ? ? ? ? ? ? ? ? ? ? ? @ tag->hdr.tag = ATAG_NONE;
> >> > -1:
> >> > +__mach_type:
> >> > + ? ? ? .long ? MACH_TYPE
> >> > +__image_start:
> >> > + ? ? ? .long ? _start
> >> > +__image_end:
> >> > + ? ? ? .long ? _got_end
> >> > +__load_base:
> >> > + ? ? ? .long ? CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> >>
> >> Just curious, where does these 32Mb come from?
> >
> > IMHO Its fairly arbitrary where the zImage is copied to.
> > I chose 32Mb as it is the same place that uboot puts images.
> 
> That makes sense.
> 
> >> Say that a board with be equipped with less than 32Mb, how is that handled?
> >
> > It isn't.
> >
> > An alternate approach might be to just place it at the end of the
> > destination, which can be approximated using 4 * the compressed image size.
> > The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
> >
> > I'm open to other ideas about where to copy the zImage to.
> 
> What's stopping us from loading the kernel image from MMC straight to
> CONFIG_MEMORY_START?

Because what is expected in the end is an uncompressed
kernel at CONFIG_MEMORY_START + TEXT_OFFSET and the compressed
image won't fit between in TEXT_OFFSET bytes.

> At least that's simple - but I suppose it isn't working right out of the box.
> 
> Judging by the code in arch/arm/boot/compressed/head.S it looks like
> the zImage should be able to relocate itself.
> 
> Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
> arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
> boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
> kernel is executing from flash or rom, which is true for our NOR flash
> boot case, but is false when we're booting from MMC.

Could you be more specific about which bits of head.S you are looking at?

Re: [patch 3/3] mmc, ARM: Add zboot from MMC support for SuperH

[Simon Horman]

On Mon, Dec 06, 2010 at 10:33:40AM +0900, Magnus Damm wrote:
> On Mon, Dec 6, 2010 at 10:11 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Dec 06, 2010 at 09:51:55AM +0900, Magnus Damm wrote:
> >> On Mon, Dec 6, 2010 at 9:12 AM, Simon Horman <horms@verge.net.au> wrote:
> >> > This allows a ROM-able zImage to be written to MMC and
> >> > for SuperH Mobile ARM to boot directly from the MMCIF
> >> > 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: Magnus Damm <magnus.damm@gmail.com>
> >> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >> >
> >> > ---
> >> >
> >> > This patch depends on "ARM: 6514/1: mach-shmobile: Add zboot support for
> >> > SuperH Mobile ARM" which has been merged into the devel branch
> >> > of Russell King's linux-2.6-arm tree.
> >> >
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
> >> > =================================> >> > --- /dev/null   1970-01-01 00:00:00.000000000 +0000
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c       2010-12-06 09:11:42.000000000 +0900
> >> > @@ -0,0 +1,99 @@
> >> > +/*
> >> > + * sh7372 MMCIF loader
> >> > + *
> >> > + * Copyright (C) 2010 Magnus Damm
> >> > + * Copyright (C) 2010 Simon Horman
> >> > + *
> >> > + * This file is subject to the terms and conditions of the GNU General Public
> >> > + * License.  See the file "COPYING" in the main directory of this archive
> >> > + * for more details.
> >> > + */
> >> > +
> >> > +#include <linux/mmc/sh_mmcif.h>
> >> > +#include <mach/mmcif.h>
> >> > +
> >> > +#define MMCIF_BASE      (void __iomem *)0xe6bd0000
> >> > +
> >> > +#define PORT84CR       0xe6050054
> >> > +#define PORT85CR       0xe6050055
> >> > +#define PORT86CR       0xe6050056
> >> > +#define PORT87CR       0xe6050057
> >> > +#define PORT88CR       0xe6050058
> >> > +#define PORT89CR       0xe6050059
> >> > +#define PORT90CR       0xe605005a
> >> > +#define PORT91CR       0xe605005b
> >> > +#define PORT92CR       0xe605005c
> >> > +#define PORT99CR       0xe6050063
> >> > +#define PORT185CR      0xe60520b9
> >> > +#define PORT186CR      0xe60520ba
> >> > +#define PORT187CR      0xe60520bb
> >> > +#define PORT188CR      0xe60520bc
> >> > +
> >> > +#define SMSTPCR3       0xe615013c
> >> > +
> >> > +/* SH7372 specific MMCIF loader
> >> > + *
> >> > + * loads the zImage from an MMC card starting from block 1.
> >> > + *
> >> > + * The image must be start with a vrl4 header and
> >> > + * the zImage must start at offset 512 of the image. That is,
> >> > + * at block 2 (=byte 1024) on the media
> >> > + *
> >> > + * Use the following line to write the vrl4 formated zImage
> >> > + * to an MMC card
> >> > + * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
> >> > + */
> >> > +asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
> >> > +{
> >> > +       /* 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);
> >>
> >> Aren't these LEDs a board-specific property?
> >>
> >> I believe the rest of the code is common across multiple boards, so
> >> making it fully sharable would be nice.
> >>
> >> Please break out the board-specific somehow, perhaps into
> >> mmcif_update_progress().
> >
> > Sure, perhaps we could just move this initialisation into head-ap4evb.txt?
> 
> Sounds good!
> 
> > Or remove mmcif_update_progress() all together?
> 
> Nah, I prefer to keep some kind of abstraction for the progress meter.
> 
> >> > Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
> >> > =================================> >> > --- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S 2010-12-06 09:11:35.000000000 +0900
> >> > +++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S      2010-12-06 09:11:42.000000000 +0900
> >> > @@ -40,14 +59,19 @@ __atags:@ tag #1
> >> >        @ tag #3
> >> >        .long   0                       @ tag->hdr.size = 0
> >> >        .long   0                       @ tag->hdr.tag = ATAG_NONE;
> >> > -1:
> >> > +__mach_type:
> >> > +       .long   MACH_TYPE
> >> > +__image_start:
> >> > +       .long   _start
> >> > +__image_end:
> >> > +       .long   _got_end
> >> > +__load_base:
> >> > +       .long   CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
> >>
> >> Just curious, where does these 32Mb come from?
> >
> > IMHO Its fairly arbitrary where the zImage is copied to.
> > I chose 32Mb as it is the same place that uboot puts images.
> 
> That makes sense.
> 
> >> Say that a board with be equipped with less than 32Mb, how is that handled?
> >
> > It isn't.
> >
> > An alternate approach might be to just place it at the end of the
> > destination, which can be approximated using 4 * the compressed image size.
> > The same assumption is made in arch/arm/boot/compressed/vmlinux.lds.in.
> >
> > I'm open to other ideas about where to copy the zImage to.
> 
> What's stopping us from loading the kernel image from MMC straight to
> CONFIG_MEMORY_START?

Because what is expected in the end is an uncompressed
kernel at CONFIG_MEMORY_START + TEXT_OFFSET and the compressed
image won't fit between in TEXT_OFFSET bytes.

> At least that's simple - but I suppose it isn't working right out of the box.
> 
> Judging by the code in arch/arm/boot/compressed/head.S it looks like
> the zImage should be able to relocate itself.
> 
> Perhaps the code wrapped in #ifndef CONFIG_ZBOOT_ROM in
> arch/arm/boot/compressed/head.S isn't enabled properly for the MMC
> boot case. It looks like the CONFIG_ZBOOT_ROM=y case assumes that the
> kernel is executing from flash or rom, which is true for our NOR flash
> boot case, but is false when we're booting from MMC.

Could you be more specific about which bits of head.S you are looking at?

Re: [patch 3/3 v2] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
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: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

 Documentation/arm/SH-Mobile/Makefile                |    8
 Documentation/arm/SH-Mobile/vrl4.c                  |  167 +++++++++++++
 Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt     |   29 ++
 arch/arm/Kconfig                                    |   12
 arch/arm/boot/compressed/Makefile                   |    6
 arch/arm/boot/compressed/head-shmobile.S            |   31 ++
 arch/arm/boot/compressed/mmcif-sh7372.c             |   86 ++++++
 arch/arm/mach-shmobile/include/mach/head-ap4evb.txt |    6
 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h   |   12
 arch/arm/mach-shmobile/include/mach/mmcif.h         |   16 +
 10 files changed, 373 insertions(+)

This patch depends on:
* "ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM"
  which has been merged into the devel branch of Russell King's
  linux-2.6-arm tree.
* "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
* "mmc, sh: Remove sh_mmcif_boot_slurp()"

v2 Addressed comments by Magnus Damm:
* Fix copyright in vrl4.c
* Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
* Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
  as this is considered board-specific.

Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c	2010-12-06 16:40:43.000000000 +0900
@@ -0,0 +1,86 @@
+/*
+ * sh7372 MMCIF loader
+ *
+ * Copyright (C) 2010 Magnus Damm
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/mmc/sh_mmcif.h>
+#include <mach/mmcif.h>
+
+#define MMCIF_BASE      (void __iomem *)0xe6bd0000
+
+#define PORT84CR	0xe6050054
+#define PORT85CR	0xe6050055
+#define PORT86CR	0xe6050056
+#define PORT87CR	0xe6050057
+#define PORT88CR	0xe6050058
+#define PORT89CR	0xe6050059
+#define PORT90CR	0xe605005a
+#define PORT91CR	0xe605005b
+#define PORT92CR	0xe605005c
+#define PORT99CR	0xe6050063
+
+#define SMSTPCR3	0xe615013c
+
+/* SH7372 specific MMCIF loader
+ *
+ * loads the zImage from an MMC card starting from block 1.
+ *
+ * The image must be start with a vrl4 header and
+ * the zImage must start at offset 512 of the image. That is,
+ * at block 2 (=byte 1024) on the media
+ *
+ * Use the following line to write the vrl4 formated zImage
+ * 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)
+{
+	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+
+	/* Initialise MMC
+	 * registers: PORT84CR-PORT92CR
+	 *            (MMCD0_0-MMCD0_7,MMCCMD0 Control)
+	 * value: 0x04 - select function 4
+	 */
+	 __raw_writeb(0x04, PORT84CR);
+	 __raw_writeb(0x04, PORT85CR);
+	 __raw_writeb(0x04, PORT86CR);
+	 __raw_writeb(0x04, PORT87CR);
+	 __raw_writeb(0x04, PORT88CR);
+	 __raw_writeb(0x04, PORT89CR);
+	 __raw_writeb(0x04, PORT90CR);
+	 __raw_writeb(0x04, PORT91CR);
+	 __raw_writeb(0x04, PORT92CR);
+
+	/* Initialise MMC
+	 * registers: PORT99CR (MMCCLK0 Control)
+	 * value: 0x10 | 0x04 - enable output | select function 4
+	 */
+	__raw_writeb(0x14, PORT99CR);
+
+	/* Enable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+
+	/* setup MMCIF hardware */
+	sh_mmcif_boot_init(MMCIF_BASE);
+
+	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+
+	/* load kernel via MMCIF interface */
+	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is at block 2 */
+			      (len + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS, buf);
+
+
+	/* Disable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+}
Index: linux-2.6-ap4/arch/arm/boot/compressed/Makefile
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/Makefile	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_SHMOBILE),y)
 OBJS		+= head-shmobile.o
 endif
 
+ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
+ifeq ($(CONFIG_ARCH_SH7372),y)
+OBJS		+= mmcif-sh7372.o
+endif
+endif
+
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 16:43:49.000000000 +0900
@@ -25,6 +25,37 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
+#ifdef CONFIG_ZBOOT_ROM_MMCIF
+	/* Load image from MMC */
+	adr	sp, __tmp_stack
+	add	sp, sp, #128
+	ldr	r0, __image_start
+	ldr	r1, __image_end
+	subs	r1, r1, r0
+	ldr	r0, __load_base
+	mov	lr, pc
+	b	mmcif_loader
+
+	/* Jump to loaded code */
+	ldr	r0, __loaded
+	ldr	r1, __image_start
+	sub	r0, r0, r1
+	ldr	r1, __load_base
+	add	pc, r0, r1
+
+__image_start:
+	.long	_start
+__image_end:
+	.long	_got_end
+__load_base:
+	.long	CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
+__loaded:
+	.long	__loaded
+	.align
+__tmp_stack:
+	.space	128
+#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+
 	b	1f
 __atags:@ tag #1
 	.long	12			@ tag->hdr.size = tag_size(tag_core);
Index: linux-2.6-ap4/arch/arm/Kconfig
===================================================================
--- linux-2.6-ap4.orig/arch/arm/Kconfig	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/Kconfig	2010-12-06 16:40:34.000000000 +0900
@@ -1587,6 +1587,18 @@ 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.
 
+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.
+
 config CMDLINE
 	string "Default kernel command string"
 	default ""
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,12 @@
+#ifndef MMCIF_AP4EB_H
+#define MMCIF_AP4EB_H
+
+#define PORTR191_160DR 0xe6056014
+
+static void mmcif_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMCIF_AP4EB_H */
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,16 @@
+#ifndef MMCIF_H
+#define MMCIF_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmcif-ap4eb.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMCIF_H */
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+	rm -f *.o $(BIN)
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c	2010-12-06 10:12:05.000000000 +0900
@@ -0,0 +1,167 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *	  dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+	uint32_t magic1;
+	uint32_t reserved1;
+	uint32_t magic2;
+	uint32_t reserved2;
+	uint16_t copy_size;
+	uint16_t boot_options;
+	uint32_t reserved3;
+	uint32_t start_address;
+	uint32_t reserved4;
+	uint32_t reserved5;
+	char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)					\
+	struct hdr (h) = {				\
+		.magic1 =	0xea000000,		\
+		.reserved1 =	0x56,			\
+		.magic2 =	0xe59ff008,		\
+		.reserved3 =	0x1 }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS	9
+#define ALIGN		(1 << ALIGN_BITS)
+
+#define START_BASE	0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 40 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define	MAX_BOOT_PROG_LEN (40 * 512)
+
+#define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = read(fd, buf + offset, count - offset);
+		if (!l)
+			break;
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("read");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = write(fd, buf + offset, count - offset);
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("write");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+	size_t i = len;
+
+	while (i--) {
+		const char x = 0;
+		if (do_write(fd, &x, 1) < 0)
+			return -1;
+	}
+
+	return len;
+}
+
+int main(void)
+{
+	DECLARE_HDR(hdr);
+	char boot_program[MAX_BOOT_PROG_LEN];
+	size_t aligned_hdr_len, alligned_prog_len;
+	ssize_t prog_len;
+
+	prog_len = do_read(0, boot_program, sizeof(boot_program));
+	if (prog_len <= 0)
+		return -1;
+
+	aligned_hdr_len = ROUND_UP(sizeof(hdr));
+	hdr.start_address = START_BASE + aligned_hdr_len;
+	alligned_prog_len = ROUND_UP(prog_len);
+	hdr.copy_size = aligned_hdr_len + alligned_prog_len;
+
+	if (do_write(1, &hdr, sizeof(hdr)) < 0)
+		return -1;
+	if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+		return -1;
+
+	if (do_write(1, boot_program, prog_len) < 0)
+		return 1;
+
+	/* Write out the rest of the kernel */
+	while (1) {
+		prog_len = do_read(0, boot_program, sizeof(boot_program));
+		if (prog_len < 0)
+			return 1;
+		if (prog_len == 0)
+			break;
+		if (do_write(1, boot_program, prog_len) < 0)
+			return 1;
+	}
+
+	return 0;
+}
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF 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 AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card at sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt
===================================================================
--- linux-2.6-ap4.orig/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:34.000000000 +0900
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:43.000000000 +0900
@@ -85,3 +85,9 @@ ED 0xE6150004, 0x80331050
 WAIT 1, 0xFE40009C
 
 ED 0xE6150354, 0x00000002
+
+LIST "LED1-4"
+EB 0xE60520B9, 0x10
+EB 0xE60520BA, 0x10
+EB 0xE60520BB, 0x10
+EB 0xE60520BC, 0x10

[patch 3/3 v2] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM

[Simon Horman]

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
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: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

 Documentation/arm/SH-Mobile/Makefile                |    8
 Documentation/arm/SH-Mobile/vrl4.c                  |  167 +++++++++++++
 Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt     |   29 ++
 arch/arm/Kconfig                                    |   12
 arch/arm/boot/compressed/Makefile                   |    6
 arch/arm/boot/compressed/head-shmobile.S            |   31 ++
 arch/arm/boot/compressed/mmcif-sh7372.c             |   86 ++++++
 arch/arm/mach-shmobile/include/mach/head-ap4evb.txt |    6
 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h   |   12
 arch/arm/mach-shmobile/include/mach/mmcif.h         |   16 +
 10 files changed, 373 insertions(+)

This patch depends on:
* "ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM"
  which has been merged into the devel branch of Russell King's
  linux-2.6-arm tree.
* "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
* "mmc, sh: Remove sh_mmcif_boot_slurp()"

v2 Addressed comments by Magnus Damm:
* Fix copyright in vrl4.c
* Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
* Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
  as this is considered board-specific.

Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c	2010-12-06 16:40:43.000000000 +0900
@@ -0,0 +1,86 @@
+/*
+ * sh7372 MMCIF loader
+ *
+ * Copyright (C) 2010 Magnus Damm
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/mmc/sh_mmcif.h>
+#include <mach/mmcif.h>
+
+#define MMCIF_BASE      (void __iomem *)0xe6bd0000
+
+#define PORT84CR	0xe6050054
+#define PORT85CR	0xe6050055
+#define PORT86CR	0xe6050056
+#define PORT87CR	0xe6050057
+#define PORT88CR	0xe6050058
+#define PORT89CR	0xe6050059
+#define PORT90CR	0xe605005a
+#define PORT91CR	0xe605005b
+#define PORT92CR	0xe605005c
+#define PORT99CR	0xe6050063
+
+#define SMSTPCR3	0xe615013c
+
+/* SH7372 specific MMCIF loader
+ *
+ * loads the zImage from an MMC card starting from block 1.
+ *
+ * The image must be start with a vrl4 header and
+ * the zImage must start at offset 512 of the image. That is,
+ * at block 2 (=byte 1024) on the media
+ *
+ * Use the following line to write the vrl4 formated zImage
+ * 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)
+{
+	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+
+	/* Initialise MMC
+	 * registers: PORT84CR-PORT92CR
+	 *            (MMCD0_0-MMCD0_7,MMCCMD0 Control)
+	 * value: 0x04 - select function 4
+	 */
+	 __raw_writeb(0x04, PORT84CR);
+	 __raw_writeb(0x04, PORT85CR);
+	 __raw_writeb(0x04, PORT86CR);
+	 __raw_writeb(0x04, PORT87CR);
+	 __raw_writeb(0x04, PORT88CR);
+	 __raw_writeb(0x04, PORT89CR);
+	 __raw_writeb(0x04, PORT90CR);
+	 __raw_writeb(0x04, PORT91CR);
+	 __raw_writeb(0x04, PORT92CR);
+
+	/* Initialise MMC
+	 * registers: PORT99CR (MMCCLK0 Control)
+	 * value: 0x10 | 0x04 - enable output | select function 4
+	 */
+	__raw_writeb(0x14, PORT99CR);
+
+	/* Enable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+
+	/* setup MMCIF hardware */
+	sh_mmcif_boot_init(MMCIF_BASE);
+
+	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+
+	/* load kernel via MMCIF interface */
+	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is@block 2 */
+			      (len + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS, buf);
+
+
+	/* Disable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+}
Index: linux-2.6-ap4/arch/arm/boot/compressed/Makefile
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/Makefile	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_SHMOBILE),y)
 OBJS		+= head-shmobile.o
 endif
 
+ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
+ifeq ($(CONFIG_ARCH_SH7372),y)
+OBJS		+= mmcif-sh7372.o
+endif
+endif
+
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
===================================================================
--- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 16:43:49.000000000 +0900
@@ -25,6 +25,37 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
+#ifdef CONFIG_ZBOOT_ROM_MMCIF
+	/* Load image from MMC */
+	adr	sp, __tmp_stack
+	add	sp, sp, #128
+	ldr	r0, __image_start
+	ldr	r1, __image_end
+	subs	r1, r1, r0
+	ldr	r0, __load_base
+	mov	lr, pc
+	b	mmcif_loader
+
+	/* Jump to loaded code */
+	ldr	r0, __loaded
+	ldr	r1, __image_start
+	sub	r0, r0, r1
+	ldr	r1, __load_base
+	add	pc, r0, r1
+
+__image_start:
+	.long	_start
+__image_end:
+	.long	_got_end
+__load_base:
+	.long	CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
+__loaded:
+	.long	__loaded
+	.align
+__tmp_stack:
+	.space	128
+#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+
 	b	1f
 __atags:@ tag #1
 	.long	12			@ tag->hdr.size = tag_size(tag_core);
Index: linux-2.6-ap4/arch/arm/Kconfig
===================================================================
--- linux-2.6-ap4.orig/arch/arm/Kconfig	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/Kconfig	2010-12-06 16:40:34.000000000 +0900
@@ -1587,6 +1587,18 @@ 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.
 
+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.
+
 config CMDLINE
 	string "Default kernel command string"
 	default ""
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,12 @@
+#ifndef MMCIF_AP4EB_H
+#define MMCIF_AP4EB_H
+
+#define PORTR191_160DR 0xe6056014
+
+static void mmcif_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMCIF_AP4EB_H */
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,16 @@
+#ifndef MMCIF_H
+#define MMCIF_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmcif-ap4eb.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMCIF_H */
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+	rm -f *.o $(BIN)
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c	2010-12-06 10:12:05.000000000 +0900
@@ -0,0 +1,167 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *	  dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+	uint32_t magic1;
+	uint32_t reserved1;
+	uint32_t magic2;
+	uint32_t reserved2;
+	uint16_t copy_size;
+	uint16_t boot_options;
+	uint32_t reserved3;
+	uint32_t start_address;
+	uint32_t reserved4;
+	uint32_t reserved5;
+	char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)					\
+	struct hdr (h) = {				\
+		.magic1 =	0xea000000,		\
+		.reserved1 =	0x56,			\
+		.magic2 =	0xe59ff008,		\
+		.reserved3 =	0x1 }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS	9
+#define ALIGN		(1 << ALIGN_BITS)
+
+#define START_BASE	0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 40 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define	MAX_BOOT_PROG_LEN (40 * 512)
+
+#define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = read(fd, buf + offset, count - offset);
+		if (!l)
+			break;
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("read");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = write(fd, buf + offset, count - offset);
+		if (l < 0) {
+			if (errno == EAGAIN || errno == EWOULDBLOCK)
+				continue;
+			perror("write");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+	size_t i = len;
+
+	while (i--) {
+		const char x = 0;
+		if (do_write(fd, &x, 1) < 0)
+			return -1;
+	}
+
+	return len;
+}
+
+int main(void)
+{
+	DECLARE_HDR(hdr);
+	char boot_program[MAX_BOOT_PROG_LEN];
+	size_t aligned_hdr_len, alligned_prog_len;
+	ssize_t prog_len;
+
+	prog_len = do_read(0, boot_program, sizeof(boot_program));
+	if (prog_len <= 0)
+		return -1;
+
+	aligned_hdr_len = ROUND_UP(sizeof(hdr));
+	hdr.start_address = START_BASE + aligned_hdr_len;
+	alligned_prog_len = ROUND_UP(prog_len);
+	hdr.copy_size = aligned_hdr_len + alligned_prog_len;
+
+	if (do_write(1, &hdr, sizeof(hdr)) < 0)
+		return -1;
+	if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+		return -1;
+
+	if (do_write(1, boot_program, prog_len) < 0)
+		return 1;
+
+	/* Write out the rest of the kernel */
+	while (1) {
+		prog_len = do_read(0, boot_program, sizeof(boot_program));
+		if (prog_len < 0)
+			return 1;
+		if (prog_len == 0)
+			break;
+		if (do_write(1, boot_program, prog_len) < 0)
+			return 1;
+	}
+
+	return 0;
+}
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF 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 AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card@sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt
===================================================================
--- linux-2.6-ap4.orig/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:34.000000000 +0900
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:43.000000000 +0900
@@ -85,3 +85,9 @@ ED 0xE6150004, 0x80331050
 WAIT 1, 0xFE40009C
 
 ED 0xE6150354, 0x00000002
+
+LIST "LED1-4"
+EB 0xE60520B9, 0x10
+EB 0xE60520BA, 0x10
+EB 0xE60520BB, 0x10
+EB 0xE60520BC, 0x10

Re: [patch 3/3 v2] mmc, ARM: Add zboot from MMC support for SuperH

[Simon Horman]

This allows a ROM-able zImage to be written to MMC and
for SuperH Mobile ARM to boot directly from the MMCIF
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: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

--- 

 Documentation/arm/SH-Mobile/Makefile                |    8
 Documentation/arm/SH-Mobile/vrl4.c                  |  167 +++++++++++++
 Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt     |   29 ++
 arch/arm/Kconfig                                    |   12
 arch/arm/boot/compressed/Makefile                   |    6
 arch/arm/boot/compressed/head-shmobile.S            |   31 ++
 arch/arm/boot/compressed/mmcif-sh7372.c             |   86 ++++++
 arch/arm/mach-shmobile/include/mach/head-ap4evb.txt |    6
 arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h   |   12
 arch/arm/mach-shmobile/include/mach/mmcif.h         |   16 +
 10 files changed, 373 insertions(+)

This patch depends on:
* "ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM"
  which has been merged into the devel branch of Russell King's
  linux-2.6-arm tree.
* "mmc, sh: Move MMCIF_PROGRESS_* into sh_mmcif.h"
* "mmc, sh: Remove sh_mmcif_boot_slurp()"

v2 Addressed comments by Magnus Damm:
* Fix copyright in vrl4.c
* Fix use of #define CONFIG_ZBOOT_ROM_MMCIF in mmcif-sh7372.c
* Initialise LED GPIO lines in head-ap4evb.txt instead of mmcif-sh7372.c
  as this is considered board-specific.

Index: linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/boot/compressed/mmcif-sh7372.c	2010-12-06 16:40:43.000000000 +0900
@@ -0,0 +1,86 @@
+/*
+ * sh7372 MMCIF loader
+ *
+ * Copyright (C) 2010 Magnus Damm
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/mmc/sh_mmcif.h>
+#include <mach/mmcif.h>
+
+#define MMCIF_BASE      (void __iomem *)0xe6bd0000
+
+#define PORT84CR	0xe6050054
+#define PORT85CR	0xe6050055
+#define PORT86CR	0xe6050056
+#define PORT87CR	0xe6050057
+#define PORT88CR	0xe6050058
+#define PORT89CR	0xe6050059
+#define PORT90CR	0xe605005a
+#define PORT91CR	0xe605005b
+#define PORT92CR	0xe605005c
+#define PORT99CR	0xe6050063
+
+#define SMSTPCR3	0xe615013c
+
+/* SH7372 specific MMCIF loader
+ *
+ * loads the zImage from an MMC card starting from block 1.
+ *
+ * The image must be start with a vrl4 header and
+ * the zImage must start at offset 512 of the image. That is,
+ * at block 2 (=byte 1024) on the media
+ *
+ * Use the following line to write the vrl4 formated zImage
+ * to an MMC card
+ * # dd if=vrl4.out of=/dev/sdx bsQ2 seek=1
+ */
+asmlinkage void mmcif_loader(unsigned char *buf, unsigned long len)
+{
+	mmcif_update_progress(MMCIF_PROGRESS_ENTER);
+
+	/* Initialise MMC
+	 * registers: PORT84CR-PORT92CR
+	 *            (MMCD0_0-MMCD0_7,MMCCMD0 Control)
+	 * value: 0x04 - select function 4
+	 */
+	 __raw_writeb(0x04, PORT84CR);
+	 __raw_writeb(0x04, PORT85CR);
+	 __raw_writeb(0x04, PORT86CR);
+	 __raw_writeb(0x04, PORT87CR);
+	 __raw_writeb(0x04, PORT88CR);
+	 __raw_writeb(0x04, PORT89CR);
+	 __raw_writeb(0x04, PORT90CR);
+	 __raw_writeb(0x04, PORT91CR);
+	 __raw_writeb(0x04, PORT92CR);
+
+	/* Initialise MMC
+	 * registers: PORT99CR (MMCCLK0 Control)
+	 * value: 0x10 | 0x04 - enable output | select function 4
+	 */
+	__raw_writeb(0x14, PORT99CR);
+
+	/* Enable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & ~(1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_INIT);
+
+	/* setup MMCIF hardware */
+	sh_mmcif_boot_init(MMCIF_BASE);
+
+	mmcif_update_progress(MMCIF_PROGRESS_LOAD);
+
+	/* load kernel via MMCIF interface */
+	sh_mmcif_boot_do_read(MMCIF_BASE, 2, /* Kernel is at block 2 */
+			      (len + SH_MMCIF_BBS - 1) / SH_MMCIF_BBS, buf);
+
+
+	/* Disable clock to MMC hardware block */
+	__raw_writel(__raw_readl(SMSTPCR3) & (1 << 12), SMSTPCR3);
+
+	mmcif_update_progress(MMCIF_PROGRESS_DONE);
+}
Index: linux-2.6-ap4/arch/arm/boot/compressed/Makefile
=================================--- linux-2.6-ap4.orig/arch/arm/boot/compressed/Makefile	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -49,6 +49,12 @@ ifeq ($(CONFIG_ARCH_SHMOBILE),y)
 OBJS		+= head-shmobile.o
 endif
 
+ifeq ($(CONFIG_ZBOOT_ROM_MMCIF),y)
+ifeq ($(CONFIG_ARCH_SH7372),y)
+OBJS		+= mmcif-sh7372.o
+endif
+endif
+
 #
 # We now have a PIC decompressor implementation.  Decompressors running
 # from RAM should not define ZTEXTADDR.  Decompressors running directly
Index: linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S
=================================--- linux-2.6-ap4.orig/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/boot/compressed/head-shmobile.S	2010-12-06 16:43:49.000000000 +0900
@@ -25,6 +25,37 @@
 	/* load board-specific initialization code */
 #include <mach/zboot.h>
 
+#ifdef CONFIG_ZBOOT_ROM_MMCIF
+	/* Load image from MMC */
+	adr	sp, __tmp_stack
+	add	sp, sp, #128
+	ldr	r0, __image_start
+	ldr	r1, __image_end
+	subs	r1, r1, r0
+	ldr	r0, __load_base
+	mov	lr, pc
+	b	mmcif_loader
+
+	/* Jump to loaded code */
+	ldr	r0, __loaded
+	ldr	r1, __image_start
+	sub	r0, r0, r1
+	ldr	r1, __load_base
+	add	pc, r0, r1
+
+__image_start:
+	.long	_start
+__image_end:
+	.long	_got_end
+__load_base:
+	.long	CONFIG_MEMORY_START + 0x02000000 @ Load at 32Mb into SDRAM
+__loaded:
+	.long	__loaded
+	.align
+__tmp_stack:
+	.space	128
+#endif /* CONFIG_ZBOOT_ROM_MMCIF */
+
 	b	1f
 __atags:@ tag #1
 	.long	12			@ tag->hdr.size = tag_size(tag_core);
Index: linux-2.6-ap4/arch/arm/Kconfig
=================================--- linux-2.6-ap4.orig/arch/arm/Kconfig	2010-12-06 09:12:16.000000000 +0900
+++ linux-2.6-ap4/arch/arm/Kconfig	2010-12-06 16:40:34.000000000 +0900
@@ -1587,6 +1587,18 @@ 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.
 
+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.
+
 config CMDLINE
 	string "Default kernel command string"
 	default ""
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif-ap4eb.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,12 @@
+#ifndef MMCIF_AP4EB_H
+#define MMCIF_AP4EB_H
+
+#define PORTR191_160DR 0xe6056014
+
+static void mmcif_update_progress(int n)
+{
+	__raw_writel((__raw_readl(PORTR191_160DR) & ~(0xf << 25)) |
+		     (1 << (25 + n)), PORTR191_160DR);
+}
+
+#endif /* MMCIF_AP4EB_H */
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/mmcif.h	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,16 @@
+#ifndef MMCIF_H
+#define MMCIF_H
+
+/**************************************************
+ *
+ *		board specific settings
+ *
+ **************************************************/
+
+#ifdef CONFIG_MACH_AP4EVB
+#include "mach/mmcif-ap4eb.h"
+#else
+#error "unsupported board."
+#endif
+
+#endif /* MMCIF_H */
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/Makefile	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,8 @@
+BIN := vrl4
+
+.PHONY: all
+all: $(BIN)
+
+.PHONY: clean
+clean:
+	rm -f *.o $(BIN)
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/vrl4.c	2010-12-06 10:12:05.000000000 +0900
@@ -0,0 +1,167 @@
+/*
+ * vrl4 format generator
+ *
+ * Copyright (C) 2010 Simon Horman
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+/*
+ * usage: vrl4 < zImage > out
+ *	  dd if=out of=/dev/sdx bsQ2 seek=1 # Write the image to sector 1
+ *
+ * Reads a zImage from stdin and writes a vrl4 image to stdout.
+ * In practice this means writing a padded vrl4 header to stdout followed
+ * by the zImage.
+ *
+ * The padding places the zImage at ALIGN bytes into the output.
+ * The vrl4 uses ALIGN + START_BASE as the start_address.
+ * This is where the mask ROM will jump to after verifying the header.
+ *
+ * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
+ * That is, the mask ROM will load the padded header (ALIGN bytes)
+ * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
+ * whichever is smaller.
+ *
+ * The zImage is not modified in any way.
+ */
+
+#include <unistd.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <errno.h>
+
+struct hdr {
+	uint32_t magic1;
+	uint32_t reserved1;
+	uint32_t magic2;
+	uint32_t reserved2;
+	uint16_t copy_size;
+	uint16_t boot_options;
+	uint32_t reserved3;
+	uint32_t start_address;
+	uint32_t reserved4;
+	uint32_t reserved5;
+	char     reserved6[308];
+};
+
+#define DECLARE_HDR(h)					\
+	struct hdr (h) = {				\
+		.magic1 =	0xea000000,		\
+		.reserved1 =	0x56,			\
+		.magic2 =	0xe59ff008,		\
+		.reserved3 =	0x1 }
+
+/* Align to 512 bytes, the MMCIF sector size */
+#define ALIGN_BITS	9
+#define ALIGN		(1 << ALIGN_BITS)
+
+#define START_BASE	0xe55b0000
+
+/*
+ * With an alignment of 512 the header uses the first sector.
+ * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
+ * So there are 127 sectors left for the boot programme. But in practice
+ * Only a small portion of a zImage is needed, 40 sectors should be more
+ * than enough.
+ *
+ * Note that this sets how much of the zImage is copied by the mask ROM.
+ * The entire zImage is present after the header and is loaded
+ * by the code in the boot program (which is the first portion of the zImage).
+ */
+#define	MAX_BOOT_PROG_LEN (40 * 512)
+
+#define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
+
+ssize_t do_read(int fd, void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = read(fd, buf + offset, count - offset);
+		if (!l)
+			break;
+		if (l < 0) {
+			if (errno = EAGAIN || errno = EWOULDBLOCK)
+				continue;
+			perror("read");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t do_write(int fd, const void *buf, size_t count)
+{
+	size_t offset = 0;
+	ssize_t l;
+
+	while (offset < count) {
+		l = write(fd, buf + offset, count - offset);
+		if (l < 0) {
+			if (errno = EAGAIN || errno = EWOULDBLOCK)
+				continue;
+			perror("write");
+			return -1;
+		}
+		offset += l;
+	}
+
+	return offset;
+}
+
+ssize_t write_zero(int fd, size_t len)
+{
+	size_t i = len;
+
+	while (i--) {
+		const char x = 0;
+		if (do_write(fd, &x, 1) < 0)
+			return -1;
+	}
+
+	return len;
+}
+
+int main(void)
+{
+	DECLARE_HDR(hdr);
+	char boot_program[MAX_BOOT_PROG_LEN];
+	size_t aligned_hdr_len, alligned_prog_len;
+	ssize_t prog_len;
+
+	prog_len = do_read(0, boot_program, sizeof(boot_program));
+	if (prog_len <= 0)
+		return -1;
+
+	aligned_hdr_len = ROUND_UP(sizeof(hdr));
+	hdr.start_address = START_BASE + aligned_hdr_len;
+	alligned_prog_len = ROUND_UP(prog_len);
+	hdr.copy_size = aligned_hdr_len + alligned_prog_len;
+
+	if (do_write(1, &hdr, sizeof(hdr)) < 0)
+		return -1;
+	if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
+		return -1;
+
+	if (do_write(1, boot_program, prog_len) < 0)
+		return 1;
+
+	/* Write out the rest of the kernel */
+	while (1) {
+		prog_len = do_read(0, boot_program, sizeof(boot_program));
+		if (prog_len < 0)
+			return 1;
+		if (prog_len = 0)
+			break;
+		if (do_write(1, boot_program, prog_len) < 0)
+			return 1;
+	}
+
+	return 0;
+}
Index: linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt
=================================--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-ap4/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt	2010-12-06 10:11:54.000000000 +0900
@@ -0,0 +1,29 @@
+ROM-able zImage boot from MMC
+-----------------------------
+
+An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
+SuperH Mobile ARM will to boot directly from the MMCIF 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 AP4EB board using the developer 1A eMMC
+boot mode which is configured using the following jumper settings.
+The board used for testing required a patched mask ROM in order for
+this mode to function.
+
+   8 7 6 5 4 3 2 1
+   x|x|x|x|x| |x|
+S4 -+-+-+-+-+-+-+-
+    | | | | |x| |x on
+
+The zImage must be written to the MMC card at sector 1 (512 bytes) in
+vrl4 format. A utility vrl4 is supplied to accomplish this.
+
+e.g.
+	vrl4 < zImage | dd of=/dev/sdX bsQ2 seek=1
+
+A dual-voltage MMC 4.0 card was used for testing.
Index: linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt
=================================--- linux-2.6-ap4.orig/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:34.000000000 +0900
+++ linux-2.6-ap4/arch/arm/mach-shmobile/include/mach/head-ap4evb.txt	2010-12-06 16:40:43.000000000 +0900
@@ -85,3 +85,9 @@ ED 0xE6150004, 0x80331050
 WAIT 1, 0xFE40009C
 
 ED 0xE6150354, 0x00000002
+
+LIST "LED1-4"
+EB 0xE60520B9, 0x10
+EB 0xE60520BA, 0x10
+EB 0xE60520BB, 0x10
+EB 0xE60520BC, 0x10