[U-Boot] [PATCH] serial: Make full device search optional

[Derald Woods]

On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf <agraf at suse.de> wrote:

>
>
> On 05.02.18 01:39, Derald Woods wrote:
> > On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf <agraf at suse.de
> > <mailto:agraf at suse.de>> wrote:
> >
> >     On 01/30/2018 02:09 PM, Derald Woods wrote:
> >
> >         On Jan 30, 2018 3:17 AM, "Alexander Graf" <agraf at suse.de
> >         <mailto:agraf at suse.de> <mailto:agraf at suse.de
> >         <mailto:agraf at 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"
> >         <agraf at suse.de <mailto:agraf at suse.de>
> >                     <mailto:agraf at suse.de <mailto:agraf at 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.technical at gmail.com <mailto:woods.technical at gmail.com>
> >                     <mailto:woods.technical at gmail.com
> >         <mailto:woods.technical at gmail.com>>>
> >                     Signed-off-by: Alexander Graf <agraf at suse.de
> >         <mailto:agraf at suse.de>
> >                     <mailto:agraf at suse.de <mailto:agraf at 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