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] Terasic DE0-Nano-SoC: add support 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 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.