All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Hogan <james.hogan@imgtec.com>
To: Jonas Gorski <jogo@openwrt.org>, <linux-mips@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	John Crispin <blogic@openwrt.org>,
	Markos Chandras <markos.chandras@imgtec.com>
Subject: Re: [PATCH RFC] MIPS: add support for vmlinux appended DTB
Date: Tue, 8 Jul 2014 17:01:30 +0100	[thread overview]
Message-ID: <53BC15DA.7050602@imgtec.com> (raw)
In-Reply-To: <1404832446-31028-1-git-send-email-jogo@openwrt.org>

Hi Jonas,

On 08/07/14 16:14, Jonas Gorski wrote:
> Add support for populating initial_device_params through a dtb

initial_boot_params here and above?

> blob appended to vmlinux.

should that be vmlinux.bin? Presumably it isn't appended to the ELF file?

> 
> Signed-off-by: Jonas Gorski <jogo@openwrt.org>
> ---
> Mostly adapted from how ARM is doing it.
> 
> Sent as an RFC PATCH because I am not sure if this is the right way to
> it, and whether storing the pointer in initial_device_params is a good
> idea, or a new variable should be introduced.
> 
> The reasoning for initial_device_params is that there is no common
> MIPS interface yet, so the next best thing was using that. This also
> has the advantage of keeping the original fw_args intact.

Does it matter that this will be ignored if the bootloader does provide
a DT (initial_boot_params overwritten by early_init_dt_scan() call), and
that if no DT is provided by the bootloader the of_scan_flat_dt() calls
at the bottom of early_init_dt_scan will never happen?

> 
> This patch works for me on bcm63xx, where the bootloade expects

s/bootloade/bootloader/

> an lzma compressed kernel, so I wanted to not double compress using
> the in-kernel compressed kernel support.
> 
> Completely untested on anything except MIPS32 / big endian.
> 
>  arch/mips/Kconfig              | 18 ++++++++++++++++++
>  arch/mips/kernel/head.S        | 19 +++++++++++++++++++
>  arch/mips/kernel/vmlinux.lds.S |  6 ++++++
>  3 files changed, 43 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 3f05b56..58527cd 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -2476,6 +2476,24 @@ config USE_OF
>  	select OF_EARLY_FLATTREE
>  	select IRQ_DOMAIN
>  
> +config MIPS_APPENDED_DTB
> +	bool "Use appended device tree blob to vmlinux (EXPERIMENTAL)"
> +	depends on OF
> +	help
> +	  With this option, the boot code will look for a device tree binary
> +	  DTB) appended to vmlinux

s/DTB)/(DTB)/

vmlinux.bin again?

> +	  (e.g. cat vmlinux <filename>.dtb > vmlinux_w_dtb).

here too I think.

> +
> +	  This is meant as a backward compatibility convenience for those
> +	  systems with a bootloader that can't be upgraded to accommodate
> +	  the documented boot protocol using a device tree.
> +
> +	  Beware that there is very little in terms of protection against
> +	  this option being confused by leftover garbage in memory that might
> +	  look like a DTB header after a reboot if no actual DTB is appended
> +	  to vmlinux.  Do not leave this option active in a production kernel

maybe same here too.

Can't fault the rest though.

Cheers
James

> +	  if you don't intend to always append a DTB.
> +
>  endmenu
>  
>  config LOCKDEP_SUPPORT
> diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
> index 95afd66..72c1049 100644
> --- a/arch/mips/kernel/head.S
> +++ b/arch/mips/kernel/head.S
> @@ -93,7 +93,22 @@ NESTED(kernel_entry, 16, sp)			# kernel entry point
>  	PTR_LA	t0, 0f
>  	jr	t0
>  0:
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	PTR_LA		t0, __appended_dtb
> +	PTR_LI		t3, 0
>  
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +	PTR_LI		t1, 0xd00dfeed
> +#else
> +	PTR_LI		t1, 0xedfe0dd0
> +#endif
> +	LONG_L		t2, (t0)
> +	bne		t1, t2, not_found
> +
> +	PTR_LA		t3, __appended_dtb
> +
> +not_found:
> +#endif
>  	PTR_LA		t0, __bss_start		# clear .bss
>  	LONG_S		zero, (t0)
>  	PTR_LA		t1, __bss_stop - LONGSIZE
> @@ -107,6 +122,10 @@ NESTED(kernel_entry, 16, sp)			# kernel entry point
>  	LONG_S		a2, fw_arg2
>  	LONG_S		a3, fw_arg3
>  
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	LONG_S		t3, initial_boot_params
> +#endif
> +
>  	MTC0		zero, CP0_CONTEXT	# clear context register
>  	PTR_LA		$28, init_thread_union
>  	/* Set the SP after an empty pt_regs.  */
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 3b46f7c..8009530 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -127,6 +127,12 @@ SECTIONS
>  	}
>  
>  	PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> +
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	__appended_dtb = .;
> +	/* leave space for appended DTB */
> +	. = . + 0x100000;
> +#endif
>  	/*
>  	 * Align to 64K in attempt to eliminate holes before the
>  	 * .bss..swapper_pg_dir section at the start of .bss.  This
> 

WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Jonas Gorski <jogo@openwrt.org>, linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>,
	John Crispin <blogic@openwrt.org>,
	Markos Chandras <markos.chandras@imgtec.com>
Subject: Re: [PATCH RFC] MIPS: add support for vmlinux appended DTB
Date: Tue, 8 Jul 2014 17:01:30 +0100	[thread overview]
Message-ID: <53BC15DA.7050602@imgtec.com> (raw)
Message-ID: <20140708160130.1amFAB8Xm-lIhz2zBFwCVoC3qeuamcP136j5spgI8bw@z> (raw)
In-Reply-To: <1404832446-31028-1-git-send-email-jogo@openwrt.org>

Hi Jonas,

On 08/07/14 16:14, Jonas Gorski wrote:
> Add support for populating initial_device_params through a dtb

initial_boot_params here and above?

> blob appended to vmlinux.

should that be vmlinux.bin? Presumably it isn't appended to the ELF file?

> 
> Signed-off-by: Jonas Gorski <jogo@openwrt.org>
> ---
> Mostly adapted from how ARM is doing it.
> 
> Sent as an RFC PATCH because I am not sure if this is the right way to
> it, and whether storing the pointer in initial_device_params is a good
> idea, or a new variable should be introduced.
> 
> The reasoning for initial_device_params is that there is no common
> MIPS interface yet, so the next best thing was using that. This also
> has the advantage of keeping the original fw_args intact.

Does it matter that this will be ignored if the bootloader does provide
a DT (initial_boot_params overwritten by early_init_dt_scan() call), and
that if no DT is provided by the bootloader the of_scan_flat_dt() calls
at the bottom of early_init_dt_scan will never happen?

> 
> This patch works for me on bcm63xx, where the bootloade expects

s/bootloade/bootloader/

> an lzma compressed kernel, so I wanted to not double compress using
> the in-kernel compressed kernel support.
> 
> Completely untested on anything except MIPS32 / big endian.
> 
>  arch/mips/Kconfig              | 18 ++++++++++++++++++
>  arch/mips/kernel/head.S        | 19 +++++++++++++++++++
>  arch/mips/kernel/vmlinux.lds.S |  6 ++++++
>  3 files changed, 43 insertions(+)
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 3f05b56..58527cd 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -2476,6 +2476,24 @@ config USE_OF
>  	select OF_EARLY_FLATTREE
>  	select IRQ_DOMAIN
>  
> +config MIPS_APPENDED_DTB
> +	bool "Use appended device tree blob to vmlinux (EXPERIMENTAL)"
> +	depends on OF
> +	help
> +	  With this option, the boot code will look for a device tree binary
> +	  DTB) appended to vmlinux

s/DTB)/(DTB)/

vmlinux.bin again?

> +	  (e.g. cat vmlinux <filename>.dtb > vmlinux_w_dtb).

here too I think.

> +
> +	  This is meant as a backward compatibility convenience for those
> +	  systems with a bootloader that can't be upgraded to accommodate
> +	  the documented boot protocol using a device tree.
> +
> +	  Beware that there is very little in terms of protection against
> +	  this option being confused by leftover garbage in memory that might
> +	  look like a DTB header after a reboot if no actual DTB is appended
> +	  to vmlinux.  Do not leave this option active in a production kernel

maybe same here too.

Can't fault the rest though.

Cheers
James

> +	  if you don't intend to always append a DTB.
> +
>  endmenu
>  
>  config LOCKDEP_SUPPORT
> diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
> index 95afd66..72c1049 100644
> --- a/arch/mips/kernel/head.S
> +++ b/arch/mips/kernel/head.S
> @@ -93,7 +93,22 @@ NESTED(kernel_entry, 16, sp)			# kernel entry point
>  	PTR_LA	t0, 0f
>  	jr	t0
>  0:
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	PTR_LA		t0, __appended_dtb
> +	PTR_LI		t3, 0
>  
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +	PTR_LI		t1, 0xd00dfeed
> +#else
> +	PTR_LI		t1, 0xedfe0dd0
> +#endif
> +	LONG_L		t2, (t0)
> +	bne		t1, t2, not_found
> +
> +	PTR_LA		t3, __appended_dtb
> +
> +not_found:
> +#endif
>  	PTR_LA		t0, __bss_start		# clear .bss
>  	LONG_S		zero, (t0)
>  	PTR_LA		t1, __bss_stop - LONGSIZE
> @@ -107,6 +122,10 @@ NESTED(kernel_entry, 16, sp)			# kernel entry point
>  	LONG_S		a2, fw_arg2
>  	LONG_S		a3, fw_arg3
>  
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	LONG_S		t3, initial_boot_params
> +#endif
> +
>  	MTC0		zero, CP0_CONTEXT	# clear context register
>  	PTR_LA		$28, init_thread_union
>  	/* Set the SP after an empty pt_regs.  */
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 3b46f7c..8009530 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -127,6 +127,12 @@ SECTIONS
>  	}
>  
>  	PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> +
> +#ifdef CONFIG_MIPS_APPENDED_DTB
> +	__appended_dtb = .;
> +	/* leave space for appended DTB */
> +	. = . + 0x100000;
> +#endif
>  	/*
>  	 * Align to 64K in attempt to eliminate holes before the
>  	 * .bss..swapper_pg_dir section at the start of .bss.  This
> 

  reply	other threads:[~2014-07-08 16:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08 15:14 [PATCH RFC] MIPS: add support for vmlinux appended DTB Jonas Gorski
2014-07-08 16:01 ` James Hogan [this message]
2014-07-08 16:01   ` James Hogan
2014-07-09 12:25   ` Jonas Gorski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53BC15DA.7050602@imgtec.com \
    --to=james.hogan@imgtec.com \
    --cc=blogic@openwrt.org \
    --cc=jogo@openwrt.org \
    --cc=linux-mips@linux-mips.org \
    --cc=markos.chandras@imgtec.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.