On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf <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>> 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>> 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>> >> Signed-off-by: Alexander Graf <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. Derald _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
