From: Tim Sander <tim@krieglstein.org>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
"barebox@lists.infradead.org" <barebox@lists.infradead.org>,
Steffen Trumtrar <s.trumtrar@pengutronix.de>,
Trent Piepho <tpiepho@kymetacorp.com>
Subject: Re: [PATCH v7] Terasic DE0-Nano-SoC: add support
Date: Fri, 26 Feb 2016 09:29:43 +0100 [thread overview]
Message-ID: <3783021.3LzxP9NtCy@dabox> (raw)
In-Reply-To: <20160226072506.GN3939@pengutronix.de>
Hi
Am Freitag, 26. Februar 2016, 08:25:06 schrieb Sascha Hauer:
> On Thu, Feb 25, 2016 at 11:29:42AM +0100, Tim Sander wrote:
> > v7: eof whitespace fixes
> >
> > A Patch for supporting the Terasic DE0 NANO-SoC with barebox.
> > The pretty similar Socrates Board was taken as a starting point with
> > pulling in the memory timings/pinmux from
> > http://rocketboards.org/foswiki/view/Documentation/AtlasSoCCompileHardware
> > Design
> >
> > Signed-off-by: Tim Sander <tim@krieglstein.org>
>
> Applied, thanks. Please provide a Changelog next time, otherwise it's
> hard to guess what you actually changed.
I only included the change for the last patch not the whole stuff, so if i
understand correctly i will include all changelog files the next time.
> BTW I noticed the xload defconfig does not build anymore with this patch
> applied because the image gets too big. I searched for the reason at got
> a step closer. The SDRAM sequencer code is compiled into the image
> multiple times, one time for each board. The intention was that the
> linker throws away the unused copies via -ffunction-section and
> --gc-sections. Unfortunately this does not work because the functions in
> the different copies all end up with the same name. So for example we
> have mem_precharge_and_activate() three times in the image. Only one
> version is used, but the others can't be thrown away because they are in
> the same section.
One thing that comes to mind is gcc -flto. My experience shows that it works
much nicer than gc-sections. It hurts on large code bases though but i guess
this can be neglected with barebox.
> I hope we can solve this, otherwise we have to split the xloader
> defconfigs into multiple configs.
It would be indeed nicer if the compiler could sort that out.
Best regards
Tim
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2016-02-26 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 13:08 [PATCH v5] " Tim Sander
2016-02-15 6:30 ` Sascha Hauer
2016-02-18 16:14 ` Sascha Hauer
2016-02-25 10:18 ` [PATCH v6] " Tim Sander
2016-02-25 10:29 ` [PATCH v7] " Tim Sander
2016-02-25 10:42 ` Steffen Trumtrar
2016-02-26 7:25 ` Sascha Hauer
2016-02-26 8:29 ` Tim Sander [this message]
2016-02-26 20:39 ` Trent Piepho
2016-03-01 9:16 ` Sascha Hauer
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=3783021.3LzxP9NtCy@dabox \
--to=tim@krieglstein.org \
--cc=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
--cc=s.trumtrar@pengutronix.de \
--cc=tpiepho@kymetacorp.com \
/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