[U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig

Mon Feb 18 15:07:19 UTC 2019

On Thu, Feb 14, 2019 at 07:28:18PM +0100, Simon Goldschmidt wrote:
> Am 19.01.2019 um 17:57 schrieb Tom Rini:
> >On Sat, Jan 19, 2019 at 05:52:46PM +0100, Simon Goldschmidt wrote:
> >>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...
> >
> >Good question.  I kicked this around, harder, after posting.  I have a
> >re-work of how we generate {spl,tpl}/u-boot-spl.lds which deletes the
> >Rockchip u-boot-tpl.lds scripts (their functionality goes more broadly
> >available and is generic) and reworks PowerPC so that we don't need to
> >abuse CONFIG_SPL_TEXT_BASE for CONFIG_TPL_TEXT_BASE.  The only real
> >"big" thing that got exposed is that for the 32bit Rockchip platform
> >that uses TPL, it wasn't defining a maximum size.  With that
> >information, I think I could get comfortable doing a before/after test
> >here since if we save off the u-boot-spl.lds files a quick cmp will show
> >if any changed.
> 
> And another gentle ping on this.
> 
> Now that the series you mentioned above [1] has been merged, do you still
> plan to get CONFIG_SPL_TEXT_BASE into Kconfig for 2019.04? Or is it too late
> for that now, since rc1 has already been released?
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=87636&submitter=&state=*&q=&archive=both&delegate=

I'd still like to.  And it is "just" down to whacking the TI keystone2
stuff to not use CONFIG_SPL_TEXT_BASE the way that they have been.  So I
hope to give that another whack soon.  I did finally whack omap3 stuff
into DM+SPL so that we can enable a bunch of DM_xxx options there, so
this should get higher on my list now.

-- 
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/20190218/b1c1c0fd/attachment.sig>