diff mbox

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

Message ID 20130605075522.17653.20769.sendpatchset@w520 (mailing list archive)
State Superseded
Commit 2a58009599ff0d2bdbe7e3a9a11a0d838868634d
Headers show

Commit Message

Magnus Damm June 5, 2013, 7:55 a.m. UTC 
From: Magnus Damm <damm@opensource.se>

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 <damm@opensource.se>
---

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

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Arnd Bergmann June 5, 2013, 11:51 a.m. UTC | #1 
On Wednesday 05 June 2013, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> 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 <damm@opensource.se>

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?

	Arnd

>  arch/arm/boot/compressed/head-shmobile.S |   19 +------------------
>  1 file changed, 1 insertion(+), 18 deletions(-)
> 
> --- 0001/arch/arm/boot/compressed/head-shmobile.S
> +++ work/arch/arm/boot/compressed/head-shmobile.S	2013-06-05 11:59:06.000000000 +0900
> @@ -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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Magnus Damm June 6, 2013, 3:13 a.m. UTC | #2 
Hi Arnd,

On Wed, Jun 5, 2013 at 8:51 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 05 June 2013, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> 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 <damm@opensource.se>
>
> 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.

Cheers,

/ magnus

[1] http://marc.info/?l=linux-sh&m=131711553515485
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann June 6, 2013, 4:19 p.m. UTC | #3 
On Thursday 06 June 2013, Magnus Damm wrote:
> 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.

Ok, got it, thanks for the explanation!

> 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?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Magnus Damm June 7, 2013, 12:14 a.m. UTC | #4 
Hi Arnd,

On Fri, Jun 7, 2013 at 1:19 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 06 June 2013, Magnus Damm wrote:
>> 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.
>
> Ok, got it, thanks for the explanation!
>
>> 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?

You are correct that Emma Mobile EV2 only supports regular zImage boot
(1 above) in upstream. It is quite possible that the hardware in
theory could boot in other ways (this depends on the Mask ROM
capability), but I have not heard about anyone trying anything else.

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

As for chips coming from "Renesas Electronics", "Renesas Technology"
and if I may add "Renesas Mobile", the relationships between the
companies are quite complex so I'm afraid I can't give any good
answer.

The MMCIF/SDHI boot code was initially written for some older SH based
SoCs, but was re-implemented for ARM and sh7372 at some point. To boot
Linux directly from the reset vector it is necessary with memory
controller setup, and this is only supported by a few boards. At this
point AP4EVB and Mackerel have enough upstream coverage to boot
directly from NOR flash, MMCIF, SDHI or over USB gadget.

As for actual SoC support - which that support what boot methods much
depends on the product line and what has been implemented in the Mask
ROM. The boot mode is usually selected with a couple of pins at boot
time. Those pins are usually tied to DIP switches on the different
boards. On more recent SoCs I believe the Mask ROM allows for boot
over a wide range of I/O devices, but lately I have not seen anyone
booting Linux directly from the reset vector.

Regarding USB gadget boot and the "r_usb_boot" tool, it is known to
work on sh7372 and sh73a0.

Hope this helps,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman June 12, 2013, 2:10 p.m. UTC | #5 
On Wed, Jun 05, 2013 at 04:55:22PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> 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 <damm@opensource.se>

Thanks, I have queued this up for v3.11 in the (new) cleanup-boot branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- 0001/arch/arm/boot/compressed/head-shmobile.S
+++ work/arch/arm/boot/compressed/head-shmobile.S	2013-06-05 11:59:06.000000000 +0900
@@ -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