[U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL

Tue Jan 29 13:36:04 UTC 2019

On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford <aford173 at gmail.com> wrote:
> > > > >
> > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <fb at ltec.ch> wrote:
> > > > > >
> > > > > > Hello Adam,
> > > > > >
> > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > tell it which portions of the tree are needed early in boot time
> > > > > > >
> > > > > > > Unfortunately, with these options as-is, the system doesn't boot
> > > > > > > nor does it display anything on the UART.  I don't have a debugger
> > > > > > > readily available, but I have seen others with AM33x boards which
> > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in case
> > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > >
> > > > > > On an AM335x board I had problems when moving from embedded to separate
> > > > > > DTB. Even if deprecated you should probably give CONFIG_OF_EMBED a try.
> > > > > > If this works you could go back to CONFIG_OF_SEPARATE and probably give
> > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is working) did
> > > > > > help me quite a lot.
> > > > >
> > > > > I had to turn off DM_SERIAL temporarily to get some debugging going.
> > > > > I 'think' there is something wrong with fetching data from the device
> > > > > tree.
> > > > >
> > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  SPL_SEPARATE_BSS is set.
> > > > >
> > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 15:22:11 -0600)
> > > > > Trying to boot from MMC1
> > > > > uclass_find_device_by_seq: 0 0
> > > > >    - not found
> > > > > uclass_find_device_by_seq: 1 0
> > > > >    - not found
> > > > > spl: could not find mmc device 0. error: -19
> > > > > SPL: failed to boot from all boot devices
> > > > > ### ERROR ### Please RESET the board ###
> > > > >
> > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > >
> > > > > I am not sure what these values are support to be, but I was able to
> > > > > do a dump of my spl device tree:
> > > > >
> > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > >
> > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > With Falcon mode enabled, it immediately stops booting and/or showing
> > > > anything.  There seems to be some correlation, because disabling it
> > > > again make it work.
> > > >
> > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > it probably cannot find the serial device which may explain why
> > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > >
> > > > Might someone have any suggestions as to how to get both SPL_OF_CONFIG
> > > > with Falcon working?  I'd really like to keep that enabled by default.
> > >
> > > Note that I disabled Falcon for the space savings to keep MLO small
> > > enough, not that I noticed it failing to work.  Given that with my
> > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > and doesn't work is booting the u-boot.img I just built if there's not
> > > some overlap there.  Perhaps the addresses being used for
> > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > things?
> > >
> >
> > Is there an easy way to debug memory utilization?  We're not quite
> > getting to the point of loading u-boot.img since it cannot find the
> > MMC driver.
> >
> > Interestingly enough, when I rebased my quasi-working image with the
> > master, it died.  I can still build DM_SPL without SPL_OF_CONTROL but
> > now even with Falcon disabled, any attempts to build with
> > SPL_OF_CONTROL fail.
> > I even tried using OF_PLATDATA hoping it might reduce the memory footprint.
> >
> > I'm going to go back to 2019.01 and run some tests, but any pointers
> > on how to debug memory allocation might be helpful.
>
> When I've had to do this before I've written them out, picked values
> that must fit the hardware and rest of the situation and confirmed or
> denied my hypothesis.

I've tried to make the memory maps for logic pd boards (including
AM3517-evm) use the TI defaults as much as I can.  Interestingly
enough, when I enable DM in SPL without SPL_OF_CONTROL breaks booting
the AM3517 even when I manually add the platform data, and it doesn't
have Falcon mode enabled, so I wonder if there is something off a bit
in the omap3 initialization and/or memory usage.

When I pulled in the latest from origin/master, the part that I had
working with SPL_OF_CONTROL on the omap3_logic board stopped working.

adam
>
> --
> Tom