[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[Adam Ford]

I am trying to add DM support in SPL along with device tree support
similar to how it's being done for the omap3_logic boards.
Unfortunately, I think something is going wrong in the initialization
with CONFIG_DM enabled for SPL because I get no text data, and it
doesn't appear to boot.

I tried enabling DM in SPL and using the older platdata method without
success.  I have disabled DM_SERIAL in SPL and tried enabling the
serial debug stuff, and I get nothing.  I don't have a debugger, so
it's a bit more difficult to troubleshoot.

The main difference between the am35 and omap3 is the memory
controller, and I've tried to model the am35 after the omap3 boards I
also maintain.  I was hoping someone might have any suggestions on how
to track down the issue.  As of right now, I have OF_CONTROL working
in U-Boot and with DM disabled in SPL, everything is good.

adam

[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[Simon Goldschmidt]

Am 15.05.2019 um 20:12 schrieb Adam Ford:
> I am trying to add DM support in SPL along with device tree support
> similar to how it's being done for the omap3_logic boards.
> Unfortunately, I think something is going wrong in the initialization
> with CONFIG_DM enabled for SPL because I get no text data, and it
> doesn't appear to boot.
> 
> I tried enabling DM in SPL and using the older platdata method without
> success.  I have disabled DM_SERIAL in SPL and tried enabling the
> serial debug stuff, and I get nothing.  I don't have a debugger, so
> it's a bit more difficult to troubleshoot.
> 
> The main difference between the am35 and omap3 is the memory
> controller, and I've tried to model the am35 after the omap3 boards I
> also maintain.  I was hoping someone might have any suggestions on how
> to track down the issue.  As of right now, I have OF_CONTROL working
> in U-Boot and with DM disabled in SPL, everything is good.

I don't know that mach, but reading the files, you're calling 
'spl_early_init()' from your 'board_init_f()'. The problem I had there 
was that I did not have enough heap - and notice you need pre-reloc heap 
enabled.

spl_early_init() parses the dts and binds the drivers, and even the 
default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh, 
and of course you need CONFIG_SYS_MALLOC_F enabled when calling 
spl_early_ini() from board_init_f in SPL.

Regards,
Simon

[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[Adam Ford]

On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> Am 15.05.2019 um 20:12 schrieb Adam Ford:
> > I am trying to add DM support in SPL along with device tree support
> > similar to how it's being done for the omap3_logic boards.
> > Unfortunately, I think something is going wrong in the initialization
> > with CONFIG_DM enabled for SPL because I get no text data, and it
> > doesn't appear to boot.
> >
> > I tried enabling DM in SPL and using the older platdata method without
> > success.  I have disabled DM_SERIAL in SPL and tried enabling the
> > serial debug stuff, and I get nothing.  I don't have a debugger, so
> > it's a bit more difficult to troubleshoot.
> >
> > The main difference between the am35 and omap3 is the memory
> > controller, and I've tried to model the am35 after the omap3 boards I
> > also maintain.  I was hoping someone might have any suggestions on how
> > to track down the issue.  As of right now, I have OF_CONTROL working
> > in U-Boot and with DM disabled in SPL, everything is good.
>
> I don't know that mach, but reading the files, you're calling
> 'spl_early_init()' from your 'board_init_f()'. The problem I had there
> was that I did not have enough heap - and notice you need pre-reloc heap
> enabled.

I have a device tree setup with a variety of pre-reloc entries.  There
is an omap3-u-boot.dtsi file which sets this up.
dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio,
mmc, serial, and some misc dependencies.

Is there somewhere else I need to enable the pre-reloc stuff?

>
> spl_early_init() parses the dts and binds the drivers, and even the
> default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh,
> and of course you need CONFIG_SYS_MALLOC_F enabled when calling
> spl_early_ini() from board_init_f in SPL.

My updated defconfig file has:

CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_SYS_MALLOC_F=y


>
> Regards,
> Simon

[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[Simon Goldschmidt]

Am 15.05.2019 um 20:43 schrieb Adam Ford:
> On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
>>
>> Am 15.05.2019 um 20:12 schrieb Adam Ford:
>>> I am trying to add DM support in SPL along with device tree support
>>> similar to how it's being done for the omap3_logic boards.
>>> Unfortunately, I think something is going wrong in the initialization
>>> with CONFIG_DM enabled for SPL because I get no text data, and it
>>> doesn't appear to boot.
>>>
>>> I tried enabling DM in SPL and using the older platdata method without
>>> success.  I have disabled DM_SERIAL in SPL and tried enabling the
>>> serial debug stuff, and I get nothing.  I don't have a debugger, so
>>> it's a bit more difficult to troubleshoot.
>>>
>>> The main difference between the am35 and omap3 is the memory
>>> controller, and I've tried to model the am35 after the omap3 boards I
>>> also maintain.  I was hoping someone might have any suggestions on how
>>> to track down the issue.  As of right now, I have OF_CONTROL working
>>> in U-Boot and with DM disabled in SPL, everything is good.
>>
>> I don't know that mach, but reading the files, you're calling
>> 'spl_early_init()' from your 'board_init_f()'. The problem I had there
>> was that I did not have enough heap - and notice you need pre-reloc heap
>> enabled.
> 
> I have a device tree setup with a variety of pre-reloc entries.  There
> is an omap3-u-boot.dtsi file which sets this up.
> dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio,
> mmc, serial, and some misc dependencies.
> 
> Is there somewhere else I need to enable the pre-reloc stuff?

None that I know of. But I haven't made the transition to DM SPL, I only 
suffered when adding more DM drivers...

Are you sure that omap3-u-boot.dtsi gets auto-included? I don't know 
exactly how that automatism works...

> 
>>
>> spl_early_init() parses the dts and binds the drivers, and even the
>> default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh,
>> and of course you need CONFIG_SYS_MALLOC_F enabled when calling
>> spl_early_ini() from board_init_f in SPL.
> 
> My updated defconfig file has:
> 
> CONFIG_SYS_MALLOC_F_LEN=0x4000
> CONFIG_SYS_MALLOC_F=y

That should probably be enough :-)

Anyway, before calling spl_early_init(), I thought there shouldn't be 
anything going wrong, so debug UART should work when initialized before 
spl_early_init() is called?

Have you double-checked you're not hitting some size limit of your platform?

Regards,
Simon

[U-Boot] AM3517 SPL fails with CONFIG_DM enabled

[Alex Kiernan]

On Wed, May 15, 2019 at 7:43 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, May 15, 2019 at 1:25 PM Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
> >
> > Am 15.05.2019 um 20:12 schrieb Adam Ford:
> > > I am trying to add DM support in SPL along with device tree support
> > > similar to how it's being done for the omap3_logic boards.
> > > Unfortunately, I think something is going wrong in the initialization
> > > with CONFIG_DM enabled for SPL because I get no text data, and it
> > > doesn't appear to boot.
> > >
> > > I tried enabling DM in SPL and using the older platdata method without
> > > success.  I have disabled DM_SERIAL in SPL and tried enabling the
> > > serial debug stuff, and I get nothing.  I don't have a debugger, so
> > > it's a bit more difficult to troubleshoot.
> > >
> > > The main difference between the am35 and omap3 is the memory
> > > controller, and I've tried to model the am35 after the omap3 boards I
> > > also maintain.  I was hoping someone might have any suggestions on how
> > > to track down the issue.  As of right now, I have OF_CONTROL working
> > > in U-Boot and with DM disabled in SPL, everything is good.
> >
> > I don't know that mach, but reading the files, you're calling
> > 'spl_early_init()' from your 'board_init_f()'. The problem I had there
> > was that I did not have enough heap - and notice you need pre-reloc heap
> > enabled.
>
> I have a device tree setup with a variety of pre-reloc entries.  There
> is an omap3-u-boot.dtsi file which sets this up.
> dtc -I dtb -O dts spl/u-boot-spl.dtb lists a bunch of nodes for gpio,
> mmc, serial, and some misc dependencies.
>
> Is there somewhere else I need to enable the pre-reloc stuff?
>
> >
> > spl_early_init() parses the dts and binds the drivers, and even the
> > default CONFIG_SPL_SYS_MALLOC_F_LEN of 1 KiB wasn't enough for me. Oh,
> > and of course you need CONFIG_SYS_MALLOC_F enabled when calling
> > spl_early_ini() from board_init_f in SPL.
>
> My updated defconfig file has:
>
> CONFIG_SYS_MALLOC_F_LEN=0x4000
> CONFIG_SYS_MALLOC_F=y
>

We had a similar problem, which we tracked down to calling DM
functions before the DT was loaded (because we needed to probe GPIOs
in order to know which DT we wanted), obviously that wasn't useful,
but even with a heap of the size you've got here we were OOMing.

To figure out exactly where we'd got we it wrong we ended up running
with full malloc in SPL rather than simple malloc and chopping enough
stuff out that it all fitted, at which point actually finding out our
mistake got a lot easier (and then we could turn simple malloc back
on).

-- 
Alex Kiernan