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

[Derald Woods]

On Mon, Feb 5, 2018 at 7:13 AM, Derald Woods <woods.technical at gmail.com>
wrote:

> 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
>


​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​