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 <aford...@gmail.com> wrote: > > > > > > On Mon, Jan 28, 2019 at 2:33 PM Tom Rini <tr...@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 <tr...@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 <aford...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack <f...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot