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

Tue Feb 12 17:19:03 UTC 2019

On Tue, Feb 12, 2019 at 12:05:55PM -0500, Tom Rini wrote:
> On Mon, Feb 11, 2019 at 09:40:17PM -0600, Adam Ford wrote:
> > On Tue, Jan 29, 2019 at 7:36 AM Adam Ford <aford173 at gmail.com> wrote:
> > >
> > > 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.
> > 
> > Tom,
> > 
> > Do you know if your beagle patch still works when based on the current
> > origin/master? Is so, would you be willing to push your
> > omap3-u-boot.dtsi file?  I was able to get some limited functionality
> > by disabling features with 2019.01, but when I use the same
> > configuration, origin/master fails.  I wonder if it's related to the
> > size thread regarding the SPL size when dtb is added.
> 
> OK, I'm a dummy :)  Yes, the patches I posted work _and_ I should have
> figured this out at the time, the problem I had was that I didn't do the
> right thing to have "u-boot binary as .img" be the one that has the DTB
> rather than not.  Just now I've confirmed that what I posted before on
> f94fa0e94f36 boots to U-Boot itself.  So I'm going to do what I need to
> do to make Beagleboard work with DM and in a non-RFC way.

OK, no, that very last part is wrong, I messed up my mix-things-together
testing.  mix-and-match works, just all of this doesn't work, even when
I'm sure to have u-boot-dtb.img as what's loaded.  So, more debugging
needed.  But I get console and again, if I give it the old U-Boot file,
it works, so I feel like I'm breaking something there.

-- 
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/20190212/ad5ea53f/attachment.sig>