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

13 Feb 2018

      On Mon, Feb 5, 2018 at 7:13 AM, Derald Woods woods.technical@gmail.com
wrote:
...
On Mon, Feb 5, 2018 at 3:42 AM, Alexander Graf 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> 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>>> 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>>>

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>>>
                Signed-off-by: Alexander Graf <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.
Derald