[U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig

[Simon Goldschmidt]

Hi Tom,

Am Fr., 18. Jan. 2019, 23:02 hat Tom Rini <trini at konsulko.com> geschrieben:

> On Mon, Jan 07, 2019 at 10:12:42AM +0100, Simon Goldschmidt wrote:
> > On Wed, Jan 2, 2019 at 9:13 PM Simon Goldschmidt
> > <simon.k.r.goldschmidt at gmail.com> wrote:
> > >
> > > Hi Marek,
> > >
> > > Am 14.11.2018 um 19:51 schrieb Simon Goldschmidt:
> > > > On 07.10.2018 02:49, Tom Rini wrote:
> > > >> On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote:
> > > >>
> > > >>> Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with
> > > >>> help from moveconfig.py (only had to prepare socfpga,
> > > >>> stm32f746 and am33x/43x manually)
> > > >>>
> > > >>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> > > >>> ---
> > > >>>
> > > >>> This patch is in preparation for boot-from-FPGA for
> > > >>> socfpga cyclone5, where we need a different SPL_TEXT_BASE.
> > > >>> By moving this to Kconfig, this can then be done via
> > > >>> defconfig.
> > > >>>
> > > >>> I did notice that some defconfig files change more than
> > > >>> necessary, it seems like they are out of sync?
> > > >> So, I see at least one set of problems with the conversion, the
> am33*
> > > >> family gets put to 0x0 which isn't right.  I'm going to pull out the
> > > >> print tool I made and posted a while back and use that for
> conversion.
> > > >> Thanks for the starting point!
> > > >
> > > > Tom, what's the status on this? I still can't build an SPL for
> socfpga
> > > > gen5 boot from FPGA because I can't change SPL_TEXT_BASE.
> > > >
> > > > Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can
> we
> > > > have a separate (k)config option for socfpga only? That might be
> useful
> > > > anyway as when booting from fpga, there is no 64 KByte size limit and
> > > > the "magic value into magic register to unlock support for issuing
> warm
> > > > reset" must not be written as the SPL is not in SRAM. But that might
> > > > have its separate config option, too...
> > > >
> > > > Anyway, I just need input to know in which direction I should
> continue.
> > > > I'm waiting to get all our versions of SPL and U-Boot running from
> > > > mainline (with only board configs added for our private boards).
> > >
> > > I still cannot build an SPL to boot from FPGA since
> CONFIG_SPL_TEXT_BASE
> > > is hard-coded to OnChip RAM (while when booting from FPGA, it has to be
> > > placed into the FPGA bridge).
> > >
> > > Since both Tom and myself did not seem to have immediate luck with
> > > bringing CONFIG_SPL_TEXT_BASE to Kconfig, may I suggest to add a
> Kconfig
> > > option 'Boot from FPGA' for socfpga_gen5?
> > >
> > > Or do you have another idea at hand of how to proceed here?
> > >
> > > Please note that there might be other settings that may change when
> > > booting from FPGA, e.g. the maximum code size for SPL is not limited
> any
> > > more.
> >
> > Gentle ping?
> >
> > I'd really like to get boot-from-FPGA finally working in the next
> release!
>
> So, migrating CONFIG_SPL_TEXT_BASE.  A problem is that we don't get the
> value for CONFIG_SPL_TEXT_BASE, only CONFIG_TEXT_BASE, once we move it
> to Kconfig and are building non-SPL.  This is a problem for the TI K2
> boards.  This however can be fixed by leveraging Andrew's patch[1] as
> "ISW" is just a generic term and we can set that on the K2 platforms and
> adjust CONFIG_SYS_INIT_SP_ADDR to use that.  Next, rockchip rk3368 needs
> to be updated to make use of CONFIG_TPL_TEXT_BASE via Kconfig, which
> exists already, rather than the workaround it's doing.  Finally, some
> PowerPC boards that are using TPL are in a similar spot where they also
> need to use CONFIG_TPL_TEXT_BASE and are using the mechanic where we'll
> pass SPL_TEXT_BASE in TPL, if TPL_TEXT_BASE isn't set.
>
> So, what's all this mean?  Well, the rockchip issue looks pretty easy to
> deal with and verify, so I'll tackle that first and post something
> shortly.  The PowerPC thing also doesn't look too terrible (it's only a
> few headers) so I'll tackle that second.  And then the TI one I'll work
> on 3rd, after I get Andrew's patch merged in, which should be fairly
> soon (v3 fixed a small issue I found when merging v2).
>
> [1]: https://patchwork.ozlabs.org/patch/1026946/


So I'm still kind of waiting for this to get socfpga booting from fpga (at
least gen5 needs a special linker address for spl to boot from fpga).

Do you think this will make it for 2019.04? Because if not, I'll try to
convince Marek to add an socfpga-specific kconfig option "boot from fpga"
to finally get this working...

Thanks,
Simon