On Mon, Feb 5, 2018 at 7:13 AM, Derald Woods <woods.techni...@gmail.com> wrote:
> On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf <ag...@suse.de> wrote: > >> >> >> On 05.02.18 01:39, Derald Woods wrote: >> > On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf <ag...@suse.de >> > <mailto:ag...@suse.de>> wrote: >> > >> > On 01/30/2018 02:09 PM, Derald Woods wrote: >> > >> > On Jan 30, 2018 3:17 AM, "Alexander Graf" <ag...@suse.de >> > <mailto:ag...@suse.de> <mailto:ag...@suse.de >> > <mailto:ag...@suse.de>>> wrote: >> > >> > On 01/30/2018 12:41 AM, Derald D. Woods wrote: >> > >> > On Mon, Jan 29, 2018 at 07:46:09AM -0600, Derald Woods >> > wrote: >> > >> > On Jan 29, 2018 6:57 AM, "Alexander Graf" >> > <ag...@suse.de <mailto:ag...@suse.de> >> > <mailto:ag...@suse.de <mailto:ag...@suse.de>>> >> wrote: >> > >> > Commit 608b0c4ad4e5ec0c ("serial: Use next serial >> device >> > if probing fails") >> > added code to search for more serial devices if the >> > default one was not >> > probed correctly. >> > >> > Unfortunately, that breaks omap3_evm. So while >> > investigating why that is >> > the case, let's disable the full search for >> everyone but >> > bcm283x where it >> > is needed. >> > >> > Fixes: 608b0c4ad4e5ec0c ("serial: Use next serial >> device >> > if probing fails") >> > Reported-by: Derald D. Woods >> > <woods.techni...@gmail.com <mailto:woods.techni...@gmail.com> >> > <mailto:woods.techni...@gmail.com >> > <mailto:woods.techni...@gmail.com>>> >> > Signed-off-by: Alexander Graf <ag...@suse.de >> > <mailto:ag...@suse.de> >> > <mailto:ag...@suse.de <mailto:ag...@suse.de>>> >> > >> > --- >> > >> > Derald, could you please test this patch and verify >> it >> > does indeed unbreak >> > omap3_evm? >> > >> > The omap3_evm boots now with this patch applied on >> > master. If >> > I enable >> > SERIAL_SEARCH_ALL, it does not boot. I always build >> cleanly >> > using the >> > default config only. On failure, there is no console >> > input/output and >> > the board unresponsive. >> > >> > >> > So SPL is already broken? Can you try a known working SPL >> with >> > SERIAL_SEARCH_ALL=y U-Boot payload on top? Does that work? >> > >> > >> > I will give that path a try and see what I can discover. Again, >> > it will be later today or tomorrow before I can get to this. >> > This is why I asked what should the board code actually look >> > like. As the omap3_evm is ahead of some other OMAP34XX boards >> > currently, a good working example would be helpful. If omap3_evm >> > becomes the example, let's make it a good one. >> > >> > >> > If you want to make it a good example, don't disable >> > CONFIG_EFI_LOADER :). >> > >> > But really, the only major difference I saw between beagle and evm >> > was the fact that evm used DM in SPL. I patched that up locally (had >> > to remove ext support as the binary became too big otherwise), but >> > that didn't show the issue either. So we'll have to wait on your >> test >> > s. >> > >> > >> > >> > It looks like some compiler issue is causing the problem. I was using >> > GCC 7.2.0. When I go back to GCC 6.4.0 the board boots with >> > SERIAL_SEARCH_ALL=y. I also verified this by enabling SPL_DM_SERIAL on >> > 'omap3_beagle' and booting with SERIAL_SEARCH_ALL=y. Both GCC versions >> > compiled without error. GCC 6.4.0 is the compiler version that is >> > working for me now. The actual offending generated code will take more >> > time, for me, to sort through. >> >> Can you somehow make it break with omap3_beagle? I have one of those and >> could then help debug. >> > > > No. Not with the current default configurations. I have both the > beagleboard(3530) and beagleboard-xM(3730) at home. Their configuration > currently does not enable DM_SERIAL/SPL_DM_SERIAL. I just recently added > OF_CONTROL for them on U-Boot master. The code path is different for > without DM_SERIAL. Enabling DM_SERIAL will aid in comparison, but will > require dropping some config options to make it fit into SRAM. The '-xM' > does not have NAND. On the omap3_evm, I enable UBI in the default config. > So their are at least a couple of options that would not apply to both > beagle variants. There should probably be a separate default config file > for each variant. The 3530 beagle variant would/should be identical to the > omap3_evm. They are somewhat related from a historical perspective. I will > put together an update to the default configurations this week. Once that > is done, I will be able to make a true comparison. (omap3_evm has a 3730 > variant also) > > Derald > The issue appears to have been related to the use of CONFIG_SPL_SYS_MALLOC_SIMPLE and CONFIG_SYS_MALLOC_F_LEN in the default config. The RFC patch series is given below: https://lists.denx.de/pipermail/u-boot/2018-February/320152.html The BeagleBoard config never attempted to use CONFIG_SPL_SYS_MALLOC_SIMPLE. Derald _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot