public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Patrick DELAUNAY <patrick.delaunay@st.com>
To: u-boot@lists.denx.de
Subject: [PATCH v3] board_f.c: Insure gd->new_bootstage	alignment
Date: Thu, 9 Jan 2020 17:23:51 +0000	[thread overview]
Message-ID: <b781d83eb3ec445a882db1064573d38e@SFHDAG6NODE3.st.com> (raw)
In-Reply-To: <ce453f43d50442a48588ba3a1004fd9b@SFHDAG6NODE3.st.com>

Hi,

> From: Patrick DELAUNAY
> Sent: mardi 7 janvier 2020 13:07
> 
> Hi Patrice and Tom
> 
> > Sent: mercredi 18 décembre 2019 10:10
> >
> > Hi Simon,
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Sent: mardi 17 décembre 2019 16:46
> > >
> > > Hi Patrice,
> > >
> > > On Wed, 27 Nov 2019 at 02:11, Patrice Chotard
> > > <patrice.chotard@st.com>
> > wrote:
> > > >
> > > > In reserve_bootstage(), in case size is odd, gd->new_bootstage is
> > > > not aligned. In bootstage_relocate(), the platform hangs when
> > > > getting access to data->record[i].name.
> > > > To avoid this issue, make gd->new_bootstage 16 byte aligned.
> > > >
> > > > To insure that new_bootstage is 16 byte aligned (at least needed
> > > > for
> > > > x86_64 and ARMv8) and new_bootstage starts down to get enough
> > > > space, ALIGN_DOWN macro is used.
> > > >
> > > > Fixes: ac9cd4805c8b ("bootstage: Correct relocation algorithm")
> > > >
> > > > Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
> > > > Reviewed-by: Vikas MANOCHA <vikas.manocha@st.com>
> > > > Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> > > > Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
> >
> > For information, Patrice is absent for personal reason up to beginning next year.
> > Don't wait a fast answer.
> >
> > > For this patch I think it would be better to update reserve_fdt() to
> > > keep things aligned, assuming that is the problem.
> >
> > I don't sure that solve the issue,
> > for me the problem is only for the bootstage struct (gd->bootstage)
> > And
> > reserve_fdt() already alligne size on 32 bytes
> >
> > If I remember the Patrice analysis:
> >
> > 1- bootstage_get_size return a odd value (or at least not 16 bytes
> > aligned I don't remember).
> >
> > 2- In reserve_bootstage()
> > 	int size = bootstage_get_size();
> > 	gd->start_addr_sp -= size
> > 	=> it is a unaligned address even if gd->start_addr_sp is 32 bytes
> > alligned
> >
> > 	gd->new_bootstage = map_sysmem(gd->start_addr_sp, size);
> > 	=> also unaligned
> >
> > 3- Then during relocation, in reloc_bootstage()
> > 	gd->bootstage = gd->new_bootstage;
> >
> >
> > 4- crash occur because in next bootstage function beaucse the boostage
> > address don't respect pointer to struct allignement...
> >
> > 	struct bootstage_data *data = gd->bootstage
> >
> >
> > > At some point we should also document that reservations must keep
> > > things aligned.
> > >
> > > Perhaps this should be handled by a separate function called from
> > > all these places, which subtracts gd->start_addr_sp and ensures 16-byte
> alignment.
> >
> > Yes that can be a improvement,  but perhaps ia a second step / second serie....
> >
> > Do you think about a function called in all reversed_ functions (when
> > start_addr_sp is modified)...
> >
> > static int reserved_allign_check(void) {
> > 	/* make stack pointer 16-byte aligned */
> > 	if (gd->start_addr_sp & 0xf) {
> > 		gd->start_addr_sp -= 16;
> > 		gd->start_addr_sp &= ~0xf;
> > 	 }
> > }
> >
> > I prefer a function to reserved a size wich replace in any reserve_
> > function  the line
> > :
> > 	gd->start_addr_sp -= ...
> >
> > /* reserve size and make stack pointer 16-byte aligned */  static int
> > reserve(size_t size) {
> > 	gd->start_addr_sp -= size;
> > 	/* make stack pointer 16-byte aligned */
> > 	gd->start_addr_sp = ALIGN_DOWN(gd->start_addr_sp, 16); }
> >
> > I think I will push it, when the patrice patch will be accepted.
> 
> I am preparing this patch....
> 
> Do you think it is ok to merge the Patrice v3 proposal first on master branch for
> v2020.04 release (he just align the reserved memory for bootstage), and after I
> make my patch (16-byte align all reserved area).
> 
> or it is better to make a more generic patch v4 to replace the Patrice one.

I push a  serie, with my proposal:
[3/3] board_f.c: Insure 16 alignment of start_addr_sp and reserved memory

http://patchwork.ozlabs.org/project/uboot/list/?series=152226

As I found issue for ARM32 (I need to modify arch/arm/lib/crt0.S)
I think it is preferable that the Patrice Patch is merged in v2020.04, and my serie can live  independently.
But I can also squash of the 2 series.
 
Regards
Patrick

  reply	other threads:[~2020-01-09 17:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 12:07 [PATCH v3] board_f.c: Insure gd->new_bootstage alignment Patrick DELAUNAY
2020-01-09 17:23 ` Patrick DELAUNAY [this message]
2020-01-21 23:18   ` Tom Rini
2020-01-22 13:57     ` Patrick DELAUNAY
  -- strict thread matches above, loose matches on Subject: below --
2019-11-27  9:11 [U-Boot] " Patrice Chotard
2019-12-16 11:53 ` Patrick DELAUNAY
2019-12-17 12:52   ` Tom Rini
2019-12-18  8:26     ` Patrick DELAUNAY
2019-12-17 15:46 ` Simon Glass
2019-12-18  9:10   ` Patrick DELAUNAY

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=b781d83eb3ec445a882db1064573d38e@SFHDAG6NODE3.st.com \
    --to=patrick.delaunay@st.com \
    --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