On Tue, Jan 29, 2019 at 7:36 AM Adam Ford aford173@gmail.com wrote:
On Mon, Jan 28, 2019 at 2:33 PM Tom Rini trini@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@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@gmail.com wrote:
On Thu, Jan 24, 2019 at 7:19 AM Felix Brack fb@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.
I also submitted a question about omap3 memory mapping, and I was curious to know if you had any feedback. I am trying to remap the omap3_logic board to squeeze as much space for SPL.
adam
adam
-- Tom