sh: add romImage MMCIF boot for sh7724 and Ecovec
PATCH 1/1 sh: add romImage MMCIF boot for sh7724 and Ecovec
From: Magnus Damm <[email protected]>
This patch extends the romImage code with MMCIF support for sh7724 and the Ecovec board. With this patch applied and CONFIG_ROMIMAGE_MMCIF selected the romImage kernel image can be written to a MMC card and booted directly by the sh7724 cpu.
The MMCIF loader is put under drivers/sh for easy sharing with the sh7372 processor.
Thanks to Jeremy Baker for the initial prototype.
---
Depends on the following:
"[PATCH] sh: allow romImage data between head.S and the zero page"
arch/sh/Kconfig | 11 ++ arch/sh/boot/romimage/Makefile | 11 ++ arch/sh/boot/romimage/head.S | 29 +++++ arch/sh/boot/romimage/mmcif-sh7724.c | 94 +++++++++++++++++++ arch/sh/boot/romimage/vmlinux.scr | 1 arch/sh/include/cpu-sh4/cpu/sh7724.h | 1 drivers/sh/mmcif_loader.c | 167 ++++++++++++++++++++++++++++++++++ 7 files changed, 312 insertions(+), 2 deletions(-)
arch/sh/Kconfig +11 -0
@@ -772,6 +772,17 @@ config ENTRY_OFFSET default "0x00010000" if PAGE_SIZE_64KB default "0x00000000" +config ROMIMAGE_MMCIF + bool "Include MMCIF loader in romImage (EXPERIMENTAL)" + depends on CPU_SUBTYPE_SH7724 && EXPERIMENTAL + help + Say Y here to include experimental MMCIF loading code in + romImage. With this enabled it is possible to write the romImage + 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 romImage which in turn loads the rest the kernel + image to RAM using the MMCIF hardware block. + choice prompt "Kernel command line" optional
arch/sh/boot/romimage/Makefile +10 -1
@@ -6,8 +6,17 @@ targets := vmlinux head.o zeropage.bin piggy.o +IMAGE_ADDRESS := 0 OBJECTS = $(obj)/head.o -LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext 0 -e romstart \ + +ifeq ($(CONFIG_ROMIMAGE_MMCIF),y) +ifeq ($(CONFIG_CPU_SUBTYPE_SH7724),y) +IMAGE_ADDRESS := 0xe5200000 # ILRAM +OBJECTS += $(obj)/mmcif-sh7724.o +endif +endif + +LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(IMAGE_ADDRESS) -e romstart \ -T $(obj)/../../kernel/vmlinux.lds $(obj)/vmlinux: $(OBJECTS) $(obj)/piggy.o FORCE
arch/sh/boot/romimage/head.S +28 -1
@@ -4,14 +4,41 @@ * Board specific setup code, executed before zImage loader */ +#include <asm/page.h> +#include <cpu/addrspace.h> + .text - #include <asm/page.h> .global romstart romstart: /* include board specific setup code */ #include <mach/romimage.h> +#ifdef CONFIG_ROMIMAGE_MMCIF + mov.l load_mem_base, r4 + mov.l bytes_to_load, r5 + mov.l loader_function, r7 + jsr @r7 + mov r4, r15 + + mov.l load_mem_base, r4 + mov.l loaded_code_offs, r5 + add r4, r5 + jmp @r5 + nop + + .balign 4 +load_mem_base: + .long P1SEG | CONFIG_MEMORY_START | (1 << 20) /* 1 MiB offset */ +bytes_to_load: + .long end_data - romstart +loader_function: + .long mmcif_loader +loaded_code_offs: + .long loaded_code - romstart +loaded_code: +#endif /* CONFIG_ROMIMAGE_MMCIF */ + /* copy the empty_zero_page contents to where vmlinux expects it */ mova extra_data_pos, r0 mov.l extra_data_size, r1
arch/sh/boot/romimage/mmcif-sh7724.c new file +94 -0
94 lines not on this page · raw message
arch/sh/boot/romimage/vmlinux.scr +1 -0
@@ -3,5 +3,6 @@ SECTIONS .text : { zero_page_pos = .; *(.data) + end_data = .; } }
arch/sh/include/cpu-sh4/cpu/sh7724.h +1 -0
@@ -9,6 +9,7 @@* MD3: BSC - Area0 Bus Width (16/32-bit) [CS0BCR.9,10] * MD5: BSC - Endian Mode (L: Big, H: Little) [CMNCR.3] * MD8: Test Mode +* BOOT: FBR - Boot Mode (L: MMCIF, H: Area0) */ /* Pin Function Controller:
drivers/sh/mmcif_loader.c new file +167 -0
167 lines not on this page · raw message
Quoted 10 lines · Magnus Damm
arch/sh/boot/romimage/Makefile +2
-1@@ -6,8 +6,17 @@ targets := vmlinux head.o zeropage.bin piggy.o +IMAGE_ADDRESS := 0 OBJECTS = $(obj)/head.o -LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext 0 -e romstart \ +
arch/sh/boot/romimage/Makefile line 21
Quoted 10 lines
arch/sh/boot/romimage/Makefile +8
-0+ifeq ($(CONFIG_ROMIMAGE_MMCIF),y) +ifeq ($(CONFIG_CPU_SUBTYPE_SH7724),y) +IMAGE_ADDRESS := 0xe5200000 # ILRAM +OBJECTS += $(obj)/mmcif-sh7724.o +endif +endif + +LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(IMAGE_ADDRESS) -e romstart \ -T $(obj)/../../kernel/vmlinux.lds
This is looking pretty dire. Perhaps it's time to start looking at having per-CPU and per-machine type boot files for exporting these things. A combination of what MIPS and ARM are doing would fit this pretty well.
Quoted 6 lines
arch/sh/boot/romimage/Makefile +6
-0+#ifdef CONFIG_ROMIMAGE_MMCIF + mov.l load_mem_base, r4 + mov.l bytes_to_load, r5 + mov.l loader_function, r7 + jsr @r7 + mov r4, r15
arch/sh/boot/romimage/Makefile
Quoted 10 lines
arch/sh/boot/romimage/Makefile +10
-0+ + mov.l load_mem_base, r4 + mov.l loaded_code_offs, r5 + add r4, r5 + jmp @r5 + nop + + .balign 4 +load_mem_base: + .long P1SEG | CONFIG_MEMORY_START | (1 << 20) /* 1 MiB offset */
Not only is this totally bogus for 32-bit, it's also of questionable veracity for 29-bit. This is basically a questionable way of saying you want PAGE_OFFSET + MEMORY_START, which we already have via KERNEL_LOAD.
KERNEL_LOAD does factor in the zero page offset, which you can either mask off or account for depending on what level of flexibility you are aiming for. Note that the zero page offset is Kconfig selectable, so if anyone were to put the zero page at a 1MiB offset you would be in trouble here (and yes, boards have done this in the past, although the current worst offender is only 64kB in).
arch/sh/boot/romimage/Makefile
Quoted 3 lines
arch/sh/boot/romimage/Makefile +3
-0+#include <linux/io.h> +#include "../../../../drivers/sh/mmcif_loader.c" +
Uhm.. no. Just because sh-sci did it doesn't make it a good idea. In fact, if sh-sci does it, it's probably a stupid idea.
Quoted 12 lines
arch/sh/boot/romimage/Makefile +12
-0+/* Ecovec board specific information: + * + * Set the following to enable MMCIF boot from the MMC card in CN12: + * + * DS1.5 = OFF (SH BOOT pin set to L) + * DS2.6 = OFF (Select MMCIF on CN12 instead of SDHI1) + * DS2.7 = ON (Select MMCIF on CN12 instead of SDHI1) + * + */ +#ifdef CONFIG_SH_ECOVEC +static void set_led(int nr) +{
arch/sh/boot/romimage/Makefile
Quoted 10 lines
arch/sh/boot/romimage/Makefile +10
-0+ /* disable Hi-Z for LED pins */ + __raw_writew(__raw_readw(HIZCRA) & ~(1 << 1), HIZCRA); + + /* update progress on LED4, LED5, LED6 and LED7 */ + __raw_writeb(1 << (nr - 1), PGDR); +} +#else +#define set_led(nr) do { } while (0) +#endif +
This too, just no. You already have a romimage.h for the boards, just use that with an __ASSEMBLY__ case.
arch/sh/boot/romimage/Makefile
Quoted 8 lines
arch/sh/boot/romimage/Makefile +8
-0+/* SH7724 specific MMCIF loader + * + * loads the romImage from an MMC card starting from block 512 + * use the following line to write the romImage to an MMC card + * # dd if=arch/sh/boot/romImage of=/dev/sdx bsQ2 seekQ2 + */ +void mmcif_loader(unsigned char *buf, unsigned long no_bytes) +{
asmlinkage?
Quoted 3 lines
arch/sh/boot/romimage/Makefile +3
-0+ /* update progress */ + set_led(1); +
[snip]
Quoted 3 lines
arch/sh/boot/romimage/Makefile +3
-0+ /* update progress */ + set_led(2); +
[snip]
arch/sh/boot/romimage/Makefile
Quoted 2 lines
arch/sh/boot/romimage/Makefile +2
-0+ /* update progress */ + set_led(3);
I'm amazed that given your perverse obsession with enums that you've failed to employ them in something that would actually benefit from them in a legitimate fashion. These comments are also about as meaningful as the hardcoded values.
drivers/sh/mmcif_loader.c
Quoted 2 lines
drivers/sh/mmcif_loader.c new file +0
-0
This is definitely getting out of hand, drivers/sh/ is not a dumping ground for anything and everything. I could live with this under linux/sh_mmcif.h or so, though some of these cases are probably a bit large for inlining.
We may at some point simply have to live with building a library for things on the SH side and linking them in on the ARM side. Or if that fails, then revisit the idea of a common architecture directory.
drivers/sh/mmcif_loader.c
Quoted 2 lines
drivers/sh/mmcif_loader.c new file +2
-0+#define BLOCK_SIZE 512 +
This really wants a better name. If any of linux/io.h asm/ references bring in linux/fs.h you're going to be screwed.