[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 at 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 at 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 at gmail.com>
>> > Signed-off-by: Simon Horman <horms at 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