[U-Boot] [PATCH] configs: Migrate CONFIG_SYS_TEXT_BASE

[Adam Ford]

On Mon, Feb 12, 2018 at 6:01 PM, Tom Rini <trini at konsulko.com> wrote:
> 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).
>  */
>

If we're migrating this would it make sense to remove this content
from the include/configs/ti_armv7_common.h and place it into the
README file instead of what is currently there?  I can do that if you
think it makes the most sense.  I just don't like 'wrong' info and I
was burned before, and if the description is in two places, it can
also add to the confusion.

adam
> --
> Tom