[U-Boot] [PATCH] configs: Migrate CONFIG_SYS_TEXT_BASE
Tom Rini
trini at konsulko.com
Tue Feb 13 00:01:11 UTC 2018
On Tue, Feb 06, 2018 at 03:15:58PM -0600, Adam Ford wrote:
> On Sat, Feb 3, 2018 at 11:10 AM, Tom Rini <trini at konsulko.com> wrote:
> > On the NIOS2 and Xtensa architectures, we do not have
> > CONFIG_SYS_TEXT_BASE set. This is a strict migration of the current
> > values into the defconfig and removing them from the headers.
> >
> > I did not attempt to add more default values in and for now will leave
> > that to maintainers.
> >
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > What I wonder about, at this point, would be how hard it would be to add
> > imply FOO hex/int/str/etc value to the imply keyword. I don't want to
> > see 100 lines worth of default 0xX if Y || Z for CONFIG_SYS_TEXT_BASE as
> > that will be unmaintainable.
> > ---
>
> [snip]
>
> > new boards should not use this option.
> >
> > config SYS_TEXT_BASE
> > - depends on ARC || X86 || ARCH_UNIPHIER || ARCH_ZYNQMP || \
> > - (M68K && !TARGET_ASTRO_MCF5373L) || MICROBLAZE || MIPS || \
> > - ARCH_ZYNQ || ARCH_KEYSTONE || ARCH_OMAP2PLUS
> > + depends on !NIOS2 && !XTENSA
> > depends on !EFI_APP
> > + default 0x80800000 if ARCH_OMAP2PLUS
> > hex "Text Base"
> > help
> > - TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
> > + The address in memory that U-Boot will be running from, initially.
> >
> > - default 0x80800000 if ARCH_OMAP2PLUS
> >
>
> I have a question. I don't think anything is wrong, but
> doc/SPL/README.omap3 shows two different options for
> CONFIG_SYS_TEXT_BASE and neither of them are 0x80800000
>
> Option 1 (SPL only):
> 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
>
> Option 2 (SPL or X-Loader):
> 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
>
> I'm sure it's probably been this way for a while, but when reviewing
> the omap3_logic board (am/dm37), I noticed it's currenly using
> 0x80800000, but I am not sure how the rest of the memory map from the
> readme applies. Does this README file need to be updated or deleted?
> Will we have any memory conflicts or overlap?
So, good question. And I think it's partly due to the docs being out of
date. The docs are correct, for the time. This is best now explained
in include/configs/ti_armv7_common.h:
/*
* Place the image at the start of the ROM defined image space (per
* CONFIG_SPL_TEXT_BASE and we limit our size to the ROM-defined
* downloaded image area minus 1KiB for scratch space. We initalize DRAM as
* soon as we can so that we can place stack, malloc and BSS there. We load
* U-Boot itself into memory at 0x80800000 for legacy reasons (to not conflict
* with older SPLs). We have our BSS be placed 2MiB after this, to allow for
* the default Linux kernel address of 0x80008000 to work with most sized
* kernels, in the Falcon Mode case. We have the SPL malloc pool at the end
* of the BSS area. We suggest that the stack be placed at 32MiB after the
* start of DRAM to allow room for all of the above (handled in Kconfig).
*/
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180212/81f1283d/attachment.sig>
More information about the U-Boot
mailing list