On Mon, Feb 12, 2018 at 6:01 PM, Tom Rini <tr...@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 <tr...@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 <tr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot