From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Date: Mon, 23 Mar 2015 21:17:15 +0000
Subject: [U-Boot] [PATCH] common/board_f: make board_init_f_mem()
 independent on !CONFIG_X86
In-Reply-To: <CAPnjgZ3a4GUpChf778V=fc7UUMnvyWTkKe1aHwkQshD-z24oUg@mail.gmail.com>
References: <1426493026-6821-1-git-send-email-abrodkin@synopsys.com>
 <1427128806.2950.53.camel@synopsys.com>
 <CAPnjgZ3a4GUpChf778V=fc7UUMnvyWTkKe1aHwkQshD-z24oUg@mail.gmail.com>
Message-ID: <1427145435.2201.10.camel@synopsys.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Simon,

On Mon, 2015-03-23 at 11:26 -0600, Simon Glass wrote:
> On 23 March 2015 at 10:40, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> > Hi Tom, Simon,
> >
> > On Mon, 2015-03-16 at 11:03 +0300, Alexey Brodkin wrote:
> >> Even though board_init_f_mem() is not used on x86 today there's no
> >> reason to not use it in the future.
> >>
> >> Moreover board_init_f_mem() has nothing to do with any particular
> >> architecture so move it away from #else /* CONFIG_X86 */
> >>
> >> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> >> Cc: Simon Glass <sjg@chromium.org>
> >> Cc: Tom Rini <trini@ti.com>
> >
> > Any comments on this one?
> > This is a prerequisite for ARC updates so would be good to have it
> > merged sometime soon.
> 
> I must have missed something as it did not seem to change anything for ARC.

I meant this series -
http://lists.denx.de/pipermail/u-boot/2015-March/208179.html

In particular here I wanted to use board_init_f_mem():
http://lists.denx.de/pipermail/u-boot/2015-March/208183.html

Note that in the previous patch
http://lists.denx.de/pipermail/u-boot/2015-March/208182.html I re-used
former X86-only code sections in common/board_f.c - that's why I did
need board_init_f_mem() to be separated from #ifdef CONFIG_X86 #else - I
wanted to use both branches :)

> This breaks building on x86 though, so we can't take this patch as is. E.g.:
> 
>        x86:  +   crownbay
> +common/board_f.c: In function ?board_init_f_mem?:
> +common/board_f.c:1092:5: error: lvalue required as left operand of assignment
> +  gd = (struct global_data *)top;
> +     ^

That's why I wanted your opinion :)
Sandbox didn't show any problems and I didn't do makeall.

Because in case of X86 "gd" is an alias to get_fs_gd_ptr() we cannot do
such assignments.

So then we'll need to keep board_init_f_mem() disabled for X86 like
that:
--->8---
#ifndef CONFIG_X86
ulong board_init_f_mem(ulong top)
{
	/* 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));

#ifdef CONFIG_SYS_MALLOC_F_LEN
	top -= CONFIG_SYS_MALLOC_F_LEN;
	gd->malloc_base = top;
#endif

	return top;
}
#endif
--->8---

Do you think that's OK? If so I'll send v2 shortly.

-Alexey