[U-Boot] [PATCH v2 05/12] armV7R: K3: am654: Allow using SPL BSS pre-relocation

Simon Goldschmidt simon.k.r.goldschmidt at gmail.com
Thu Jul 25 07:01:43 UTC 2019


Hi Lokesh,

thanks for following up on this.

On Thu, Jul 25, 2019 at 6:36 AM Lokesh Vutla <lokeshvutla at ti.com> wrote:
>
> Hi Tom,
>
> On 20/07/19 9:21 PM, Tom Rini wrote:
> > On Fri, Jul 19, 2019 at 07:29:37AM +0200, Simon Goldschmidt wrote:
> >> On Fri, Jul 19, 2019 at 2:29 AM Tom Rini <trini at konsulko.com> wrote:
> >>>
> >>> On Tue, Jun 04, 2019 at 05:55:48PM -0500, Andreas Dannenberg wrote:
> >>>
> >>>> In order to be able to use more advanced driver functionality which often
> >>>> relies on having BSS initialized during early boot prior to relocation
> >>>> several things need to be in place:
> >>>>
> >>>> 1) Memory needs to be available for BSS to use. For this, we locate BSS
> >>>>    at the top of the MCU SRAM area, with the stack starting right below
> >>>>    it,
> >>>> 2) We need to move the initialization of BSS prior to entering
> >>>>    board_init_f(). We will do this with a separate commit by turning on
> >>>>    the respective CONFIG option.
> >>>>
> >>>> In this commit we also clean up the assignment of the initial SP address
> >>>> as part of the refactoring, taking into account the pre-decrement post-
> >>>> increment nature in which the SP is used on ARM.
> >>>>
> >>>> Signed-off-by: Andreas Dannenberg <dannenberg at ti.com>
> >>>
> >>> Applied to u-boot/master, thanks!
> >>
> >> Wait, why has this been merged? Unfortunately, I haven't followed this series,
> >> but in a discussion about a similar patch I sent [1], using BSS from
> >> board_init_f
> >> was turned down. And Simon Glass rather convinced me that this is the current
> >> API U-Boot has (and is documented in README).
> >>
> >> So either we must change this API and its documentation (and I would expect the
> >> author of this patch to combine the README change with the code change), or this
> >> patch would have to be rejected.
> >>
> >> Again, I'm sorry I only see this now. In thought to remember a
> >> discussion in this
> >> thread, but I clearly remember that wrong...
> >>
> >> [1] https://patchwork.ozlabs.org/patch/1057237/
> >
> > And I had missed that other thread.  Lokesh, since I think Andreas is
> > out currently can you expand a little on what we can/can't do on this
> > platform?  Thanks!
>
> The reason why BSS is needed very early in this platform is for the following
> reasons:
> - System co-processor is the central resource manager in SoC and should be
> loaded and started very early in the boot process. Without that no peripheral or
> memory can be initialized. So for loading system co-processor image, we only
> have limited SRAM and a peripheral initialized by ROM.
> - System co-processor(DMSC) is being represented as remote-core in
> Device-tree(We are strictly following DM and DT model for the entire SoC).
> - Since DM is also followed by each peripheral device and remote core, DM should
> be enabled very early and many peripheral drivers are dependent on BSS usage.
> So, BSS has been made available very early.
>
> Hope this is clear. Let me know if more details are required, I will be happy to
> explain.

Don't get me wrong: I'm not against using BSS early. I just want to ensure this
stays consistent throught U-Boot.

The reasons you stated still don't make it clear to me *why* bss is needed
early. There are other boards using DM early that don't need this. In my
opinion, DM drivers normally don't rely on BSS but keep all their state in
heap memory. If you only need BSS early because drivers rely on BSS, you might
have to fix those drivers?

Further, allowing BSS early is still against what the main README says, so I
want to raise the question again: shouldn't this main README be changed if we
suddenly allow BSS to be used early (because that main README says we can'that
do that)?

Regards,
Simon


>
> Thanks and regards,
> Lokesh


More information about the U-Boot mailing list