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

[Tom Rini]

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.

-- 
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/20190128/98694833/attachment.sig>