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

15 Feb 2018

      On Feb 15, 2018 9:00 AM, "Alexander Graf" agraf@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@gmail.com
mailto:woods.technical@gmail.com> wrote:
On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf <agraf@suse.de
<mailto:agraf@suse.de>>wrote:

    On 05.02.18 01:39, Derald Woods wrote:
    > On Tue, Jan 30, 2018 at 7:34 AM, Alexander Graf <agraf@suse.de

mailto:agraf@suse.de
...
    > <mailto:agraf@suse.de <mailto:agraf@suse.de>>> wrote:
    >
    >     On 01/30/2018 02:09 PM, Derald Woods wrote:
    >
    >         On Jan 30, 2018 3:17 AM, "Alexander Graf" <agraf@suse.de

mailto:agraf@suse.de
...
    >         <mailto:agraf@suse.de <mailto:agraf@suse.de>>
    <mailto:agraf@suse.de <mailto:agraf@suse.de>
    >         <mailto:agraf@suse.de <mailto:agraf@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@suse.de <mailto:agraf@suse.de> <mailto:

agraf@suse.de
...
    <mailto:agraf@suse.de>>
    >                     <mailto:agraf@suse.de <mailto:agraf@suse.de>

<mailto:agraf@suse.de
...
    <mailto:agraf@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@gmail.com <mailto:

woods.technical@gmail.com>
...
    <mailto:woods.technical@gmail.com
    <mailto:woods.technical@gmail.com>>
    >                     <mailto:woods.technical@gmail.com
    <mailto:woods.technical@gmail.com>
    >         <mailto:woods.technical@gmail.com <mailto:

woods.technical@gmail.com>>>>
...
    >                     Signed-off-by: Alexander Graf <agraf@suse.de

mailto:agraf@suse.de
...
    >         <mailto:agraf@suse.de <mailto:agraf@suse.de>>
    >                     <mailto:agraf@suse.de
    <mailto:agraf@suse.de> <mailto:agraf@suse.de
    <mailto:agraf@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.
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.
Derald

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

Derald Woods

Alexander Graf

tags (0)

participants (2)