From: Sam Ravnborg <sam@ravnborg.org>
To: Guan Xuetao <guanxuetao@mprc.pku.edu.cn>
Cc: 'Paul Mundt' <lethal@linux-sh.org>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv1 01/12] unicore32 core architecture: build infrastructure
Date: Sat, 8 Jan 2011 12:48:26 +0100 [thread overview]
Message-ID: <20110108114826.GA7915@merkur.ravnborg.org> (raw)
In-Reply-To: <023c01cbaf24$85a99cc0$90fcd640$@mprc.pku.edu.cn>
> > > +textofs-y := 0x00408000
> > > +
> > > +# The byte offset of the kernel image in RAM from the start of RAM.
> > > +TEXT_OFFSET := $(textofs-y)
> >
> > If you are going to have different TEXT_OFFSET's then I suggest to move
> > this to KConfig as an "hex "Text offset" config option.
> > You can set default values dependign on BSP etc.
> There is no different TEXT_OFFSET.
>
> >
> > Also defiing stuff here just to export it for use in boot/
> > has always looked like a strange concept - but many archs do so today.
> > You do not export TEXT_OFFSET but I guess this is a bug?
> I need TEXT_OFFSET for kernel/ and boot/, so export it.
I would suggest to move this to you Kconfig file.
something like this:
# The byte offset of the kernel image in RAM from the start of RAM
config UNICORE32_TEXT_OFFSET
hex
default 0x00408000
Then you have the symbol available as CONFIG_UNICORE32_TEXT_OFFSET
both in your Makefiles and in your source files.
> >
> > > +
> > > +core-y += arch/unicore32/kernel/ arch/unicore32/mm/
> > > +core-$(CONFIG_UNICORE_FPU_F64) += arch/unicore32/uc-f64/
> > > +
> > > +drivers-$(CONFIG_ARCH_PUV3) += drivers/staging/puv3/
> > > +
> > > +libs-y += arch/unicore32/lib/
> > > +# include libc.a in libs-y for string functions, like memcpy and so on.
> > > +libs-y += $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libc.a)
> > > +libs-y += $(shell $(CC) $(KBUILD_CFLAGS) -print-file-name=libgcc.a)
> > > +
> >
> > The other three archs that uses libgcc use:
> >
> > $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
> >
> > So when I read the above I am confused why it looks different than the others.
> > For libc I guess you do nto have that option and what you do is fine there.
> It's the same with -print-libgcc-file-name and -print-file-name=libgcc.a.
> And we need libc.a for string like functions.
And then they use equal methods - OK.
Sam
next prev parent reply other threads:[~2011-01-08 11:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 18:41 [PATCHv1 01/12] unicore32 core architecture: build infrastructure Guan Xuetao
2011-01-06 7:55 ` Paul Mundt
2011-01-08 5:47 ` Guan Xuetao
2011-01-08 7:20 ` Sam Ravnborg
2011-01-08 11:09 ` Guan Xuetao
2011-01-08 11:09 ` Guan Xuetao
2011-01-08 11:48 ` Sam Ravnborg [this message]
2011-01-08 11:48 ` Sam Ravnborg
2011-01-10 12:12 ` Guan Xuetao
2011-01-10 12:34 ` Sam Ravnborg
2011-01-07 0:18 ` Arnd Bergmann
2011-01-07 0:18 ` Arnd Bergmann
2011-01-08 9:22 ` Guan Xuetao
2011-01-08 14:07 ` Sam Ravnborg
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=20110108114826.GA7915@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=guanxuetao@mprc.pku.edu.cn \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).