public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jeroen Hofstee <jeroen@myspectrum.nl>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 01/10] Move board_init_f_mem() into a common location
Date: Thu, 16 Apr 2015 11:32:35 +0200	[thread overview]
Message-ID: <552F81B3.9080007@myspectrum.nl> (raw)
In-Reply-To: <1429146849-11994-2-git-send-email-sjg@chromium.org>

Hello Simon,

On 16-04-15 03:14, Simon Glass wrote:
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +ulong board_init_f_mem(ulong top)
> +{
> +	/* TODO(sjg at chromium.org): Figure out how x86 can use this */
> +#ifndef CONFIG_X86
> +	/* Leave space for the stack we are running with now */
> +	top -= 0x40;
> +
> +	top -= sizeof(struct global_data);
> +	top = ALIGN(top, 16);
> +	gd = (struct global_data *)top;
> +	memset((void *)gd, '\0', sizeof(*gd));
> +

Above piece of code is on my TODO list as well. Like x86, clang cannot
directly assign gd. What I still need to check is why this reassignment is
needed in the first place. Typically, at least for ARM, allocating an 
initial
gd in _main and copying it over in relocate suffices for common boards.

This doesn't work if there is a valid use case for needing gd before calling
main, but I am not aware of any (but haven't found time to google for any
as well, so it doesn't mean there isn't any).

That said, if there is valid reason to reassign gd, clang could do that 
if there
was a macro e.g. set_gd(new_gd) instead of a direct assignment. Since 
this is a
cross arch patchset, that might be something to consider (and likely 
solves the
"Figure out how x86 can use this" as well).

Regards,
Jeroen

  reply	other threads:[~2015-04-16  9:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16  1:13 [U-Boot] [PATCH 0/10] Make more use of board_init_f_mem() Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 01/10] Move board_init_f_mem() into a common location Simon Glass
2015-04-16  9:32   ` Jeroen Hofstee [this message]
2015-04-17 22:56     ` Simon Glass
2015-04-17 16:37   ` Masahiro Yamada
2015-04-17 22:55     ` Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 02/10] board_init_f_mem(): Don't require memset() Simon Glass
2015-04-16  4:25   ` Wolfgang Denk
2015-04-19 14:22     ` Simon Glass
2015-04-21  3:42   ` Masahiro Yamada
2015-04-21  3:47     ` Simon Glass
2015-04-21  4:30       ` Masahiro Yamada
2015-04-24  4:15         ` Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 03/10] board_init_f_mem(): Round down for stack alignment Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 04/10] board_init_f_mem(): Don't create an unused early malloc() area Simon Glass
2015-04-20 12:12   ` Masahiro Yamada
2015-04-16  1:14 ` [U-Boot] [PATCH 05/10] arm: Adjust start-up code to use board_init_f_mem() Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 06/10] arm64: " Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 07/10] x86: Add a TODO to call board_init_f_mem() Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 08/10] microblaze: " Simon Glass
2015-04-16  1:14 ` [U-Boot] [PATCH 09/10] zynq: Move SPL console init out of board_init_f() Simon Glass
2015-04-20 12:15   ` Masahiro Yamada
2015-04-16  1:14 ` [U-Boot] [PATCH 10/10] Revert "ARM: zynq: disable CONFIG_SYS_MALLOC_F to fix MMC boot" Simon Glass
2015-04-20 12:08   ` Masahiro Yamada

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=552F81B3.9080007@myspectrum.nl \
    --to=jeroen@myspectrum.nl \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox