ARM: shmobile: romImage update

From: Magnus Damm <[email protected]>

Remove the ATAGS data structure from head-shmobile.S since a default ATAGS is already provided by the code in arch/arm/kernel/atags_parser.c. Passing a NULL as ATAGS is valid. For actual hardware specific setup the fixup callback in the board code may be used.

Signed-off-by Magnus Damm <[email protected]>

 arch/arm/boot/compressed/head-shmobile.S |   19 +------------------
 1 file changed, 1 insertion(+), 18 deletions(-)

arch/arm/boot/compressed/head-shmobile.S +1 -18

@@ -55,26 +55,9 @@ __tmp_stack:
 __continue:
 #endif /* CONFIG_ZBOOT_ROM_MMC || CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI */
 
-	b	1f
-__atags:@ tag #1
-	.long	12			@ tag->hdr.size = tag_size(tag_core);
-	.long	0x54410001		@ tag->hdr.tag = ATAG_CORE;
-	.long   0			@ tag->u.core.flags = 0;
-	.long	0			@ tag->u.core.pagesize = 0;
-	.long	0			@ tag->u.core.rootdev = 0;
-	@ tag #2
-	.long	8			@ tag->hdr.size = tag_size(tag_mem32);
-	.long	0x54410002		@ tag->hdr.tag = ATAG_MEM;
-	.long	CONFIG_MEMORY_SIZE	@ tag->u.mem.size = CONFIG_MEMORY_SIZE;
-	.long	CONFIG_MEMORY_START	@ @ tag->u.mem.start = CONFIG_MEMORY_START;
-	@ tag #3
-	.long	0			@ tag->hdr.size = 0
-	.long	0			@ tag->hdr.tag = ATAG_NONE;
-1:
-
 	/* Set board ID necessary for boot */
 	ldr	r7, 1f				@ Set machine type register
-	adr	r8, __atags			@ Set atag register
+	mov	r8, #0				@ pass null pointer as atag
 	b	2f
 
 1 :	.long MACH_TYPE

Quoted 8 lines · Magnus Damm

From: Magnus Damm <[email protected]>

Remove the ATAGS data structure from head-shmobile.S since a default ATAGS is already provided by the code in arch/arm/kernel/atags_parser.c. Passing a NULL as ATAGS is valid. For actual hardware specific setup the fixup callback in the board code may be used.

Quoted 1 line

Signed-off-by Magnus Damm <[email protected]>

Makes sense to me, but it's not really my area of expertise. Maybe Russell has some input on this.

What about the rest of head-shmobile.S? If we ignore the mmcif boot code, can we boot an shmobile system using just the regular head.S code once we get to a multiplatform image with shmobile?

There are basically 4 types of zImages for mach-shmobile:

1) Regular zImage/uImage - DTB and ATAGS are passed from boot loader - head-shmobile.S is not used.

2) Boot directly from MASK ROM from MMCIF/SDHI - head-shmobile.S loads via MMC, sets up memory via mach/zboot.h, set ATAGS to NULL and passes MACH_TYPE to kernel, ->fixup() sets up the actual memory bank information.

3) Boot directly from NOR Flash - head-shmobile.S includes memory setup code from mach/zboot.h, passes MACH_TYPE to kernel running in flash.

4) Boot directly from MASK ROM via USB gadget - (r_usb_boot [1] runs on your PC and loads to internal SRAM) - starts same image as 3) above.

To answer your question about multiplatform images, I believe the majority case 1) above will run just fine.

Regarding 2) -> 4), those are currently very specific to a certain platform and they start directly from the reset vector which would require them to either keep the board info hard-coded in the image or somehow auto-detect board. From a hardware point of view I don' t think there is any simple way to auto detect the boards in mach-shmobile I'm afraid, so it looks to me that 2) -> 4) need to stay board-specific.

Quoted 14 lines · Magnus Damm

There are basically 4 types of zImages for mach-shmobile:

1) Regular zImage/uImage - DTB and ATAGS are passed from boot loader - head-shmobile.S is not used.

2) Boot directly from MASK ROM from MMCIF/SDHI - head-shmobile.S loads via MMC, sets up memory via mach/zboot.h, set ATAGS to NULL and passes MACH_TYPE to kernel, ->fixup() sets up the actual memory bank information.

3) Boot directly from NOR Flash - head-shmobile.S includes memory setup code from mach/zboot.h, passes MACH_TYPE to kernel running in flash.

Quoted 6 lines

4) Boot directly from MASK ROM via USB gadget - (r_usb_boot [1] runs on your PC and loads to internal SRAM) - starts same image as 3) above.

To answer your question about multiplatform images, I believe the majority case 1) above will run just fine.

Ok, got it, thanks for the explanation!

Quoted 7 lines

Regarding 2) -> 4), those are currently very specific to a certain platform and they start directly from the reset vector which would require them to either keep the board info hard-coded in the image or somehow auto-detect board. From a hardware point of view I don' t think there is any simple way to auto detect the boards in mach-shmobile I'm afraid, so it looks to me that 2) -> 4) need to stay board-specific.

Yes, that makes sense.

Just for completeness, am I guessing right that cases 2-4 are only for the previous "Renesas Technology" chips and their suggessors, while the previous NEC Emma EV2 only does the regular zImage boot?

What about the current "Renesas Electronics" parts that include NEC technology, do they all support the head-shmobile.S direct boot?

ARM: shmobile: romImage update

[PATCH 01/02] ARM: shmobile: Let romImage rely on default ATAGS [PATCH 02/02] ARM: shmobile: Remove romImage CONFIG_MEMORY_START

Rework the mach-shmobile romImage code to remove memory configuration kept in the kernel configuration.

This is one of several series of code that reworks code not to rely on CONFIG_MEMORY_START/SIZE which in turn is needed for ARCH_MULTIPLATFORM.

Signed-off-by Magnus Damm <[email protected]>

---

Written against renesas.git renesas-next-20130604v2

 arch/arm/boot/compressed/head-shmobile.S    |   21 ++-------------------
 arch/arm/mach-shmobile/include/mach/zboot.h |    2 ++
 2 files changed, 4 insertions(+), 19 deletions(-)

From: Magnus Damm <[email protected]>

Remove the ATAGS data structure from head-shmobile.S since a default ATAGS is already provided by the code in arch/arm/kernel/atags_parser.c. Passing a NULL as ATAGS is valid. For actual hardware specific setup the fixup callback in the board code may be used.

Signed-off-by Magnus Damm <[email protected]>

From: Magnus Damm <[email protected]>

Instead of relying on CONFIG_MEMORY_START for memory base address, let each romImage board header file specify this information.

This is reworks code not to rely on CONFIG_MEMORY_START which in turn is needed for ARCH_MULTIPLATFORM.

Signed-off-by Magnus Damm <[email protected]>