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

Alexander Graf agraf at suse.de
Thu Feb 15 19:37:33 UTC 2018



On 15.02.18 18:02, Derald Woods wrote:
> 
> 
> On Feb 15, 2018 9:00 AM, "Alexander Graf" <agraf at suse.de
> <mailto:agraf at suse.de>> wrote:
> 
> 
> 
>     On 13.02.18 01:00, Derald Woods wrote:
>     > On Mon, Feb 5, 2018 at 7:13 AM, Derald Woods
>     <woods.technical at gmail.com <mailto:woods.technical at gmail.com>
>     > <mailto:woods.technical at gmail.com
>     <mailto:woods.technical at gmail.com>>> wrote:
>     >
>     >     On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf <agraf at suse.de
>     <mailto:agraf at suse.de>
>     >     <mailto:agraf at suse.de <mailto: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> <mailto:agraf at suse.de
>     <mailto:agraf at suse.de>>
>     >         > <mailto:agraf at suse.de <mailto:agraf at suse.de>
>     <mailto: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>>
>     >         >         <mailto:agraf at suse.de <mailto:agraf at suse.de>
>     <mailto:agraf at suse.de <mailto:agraf at suse.de>>>
>     >         <mailto:agraf at suse.de <mailto:agraf at suse.de>
>     <mailto:agraf at suse.de <mailto:agraf at suse.de>>
>     >         >         <mailto: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>> <mailto:agraf at suse.de
>     <mailto:agraf at suse.de>
>     >         <mailto:agraf at suse.de <mailto:agraf at suse.de>>>
>     >         >                     <mailto:agraf at suse.de
>     <mailto:agraf at suse.de> <mailto:agraf at suse.de <mailto:agraf at suse.de>>
>     <mailto: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>>
>     >         <mailto:woods.technical at gmail.com
>     <mailto:woods.technical at gmail.com>
>     >         <mailto:woods.technical at gmail.com
>     <mailto:woods.technical at gmail.com>>>
>     >         >                     <mailto:woods.technical at gmail.com
>     <mailto:woods.technical at gmail.com>
>     >         <mailto:woods.technical at gmail.com
>     <mailto:woods.technical at gmail.com>>
>     >         >         <mailto: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>>
>     >         >         <mailto:agraf at suse.de <mailto:agraf at suse.de>
>     <mailto:agraf at suse.de <mailto:agraf at suse.de>>>
>     >         >                     <mailto:agraf at suse.de
>     <mailto:agraf at suse.de>
>     >         <mailto:agraf at suse.de <mailto:agraf at suse.de>>
>     <mailto: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
>     >
>     >
>     >
>     > ​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
>     <https://lists.denx.de/pipermail/u-boot/2018-February/320152.html>
>     >
>     > ​The BeagleBoard config never attempted to use
>     CONFIG_SPL_SYS_MALLOC_SIMPLE.
> 
>     So you're saying it's probably just running out of memory?
> 
> 
>     Alex
> 
> 
> The configuration mix was the key difference. The patch series has the
> details. The default malloc length set by configuration is actually
> smaller. So there are likely a mix of factors. 

Ah, so you're saying with your changes you can reproduce the problem on
the beagleboard?

I still fail to see the exact connection between the serial bug and the
patch set :)


Alex


More information about the U-Boot mailing list