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. adam > > -- > Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
