Hi Lokesh, thanks for following up on this.
On Thu, Jul 25, 2019 at 6:36 AM Lokesh Vutla <lokeshvu...@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 <tr...@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 <dannenb...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
