[U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Masahiro Yamada]

Hi Philipp,


2017-09-21 2:51 GMT+09:00 Dr. Philipp Tomsich
<philipp.tomsich at theobroma-systems.com>:
> Masahiro,
>
>> On 20 Sep 2017, at 19:34, Masahiro Yamada <yamada.masahiro at socionext.com> wrote:
>>
>> 2017-09-20 23:37 GMT+09:00 Dr. Philipp Tomsich
>> <philipp.tomsich at theobroma-systems.com>:
>>> Masahiro & Simon,
>>>
>>>> On 20 Sep 2017, at 15:49, Simon Glass <sjg at chromium.org> wrote:
>>>>
>>>> Hi Masahiro,
>>>>
>>>> On 19 September 2017 at 20:51, Masahiro Yamada
>>>> <yamada.masahiro at socionext.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>>
>>>>> 2017-09-17 6:23 GMT+09:00 Simon Glass <sjg at chromium.org>:
>>>>>
>>>>>>
>>>>>> +menu "Logging"
>>>>>> +
>>>>>> +config LOG
>>>>>> +       bool "Enable logging support"
>>>>>> +       help
>>>>>> +         This enables support for logging of status and debug messages. These
>>>>>> +         can be displayed on the console, recorded in a memory buffer, or
>>>>>> +         discarded if not needed. Logging supports various categories and
>>>>>> +         levels of severity.
>>>>>> +
>>>>>> +config SPL_LOG
>>>>>> +       bool "Enable logging support in SPL"
>>>>>> +       help
>>>>>> +         This enables support for logging of status and debug messages. These
>>>>>> +         can be displayed on the console, recorded in a memory buffer, or
>>>>>> +         discarded if not needed. Logging supports various categories and
>>>>>> +         levels of severity.
>>>>>
>>>>>
>>>>> Please note CONFIG_IS_ENABLED(LOG) is never enabled for TPL_BUILD.
>>>>>
>>>>> Since commit f1c6e1922eb57f4a212c09709801a1cc7920ffa9,
>>>>> CONFIG_IS_ENABLED(LOG) is expanded to CONFIG_TPL_LOG
>>>>> when building for TPL.
>>>>>
>>>>> Since that commit, if you add SPL_ prefixed option,
>>>>> you need to add a TPL_ one as well.
>>>>>
>>>>> I cannot believe why such a commit was accepted.
>>>>
>>>> Well either way is strange. it is strange that SPL is enabled for TPL
>>>> when really they are separate.
>>>>
>>>> We could revert that commit. But how do you think all of this SPL/TPL
>>>> control should actually work? What is intended?
>>>>
>>>> But I'm OK with not having logging in TPL until we need it.
>>>
>>> If we don’t differentiate between TPL_ and SPL_, we’ll eventually run into
>>> size issues for TPL and the $(SPL_TPL_) mechanism will not match the
>>> CONFIG_IS_ENABLED() mechanism.
>>>
>>> I don’t think that anyone will miss this much in TPL and that this can be
>>> safely left off for TPL (if space was not at a premium in TPL, then why
>>> have a TPL at all…)
>>
>>
>> The motivation of TPL is
>> the image size is really limited
>> for the secondary boot loader in some cases.
>>
>>
>> Instead of:
>>  SPL -> TPL -> U-Boot full
>
> Note that this was retro-actively defined to be
>         TPL -> SPL -> U-Boot full
> by Tom at some point and reiterated in
>         https://lists.denx.de/pipermail/u-boot/2017-July/299266.html



Thanks.  I did not know that this flip had already happened.


In fact, I am probably the first man who suggested it.


Here is the history.


1. Scott Wood introduced TPL to support some freescale chip,
   which had only 4KB memory footprint for the second loader
   https://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/tpl-presentation.pdf

   At this point, the boot order was:  SPL -> TPL -> U-Boot
   And TPL means "Tertiary Program Loader".


2.  I imported Kbuild and Kconfig to U-Boot.


3.  During the migration of Kconfig, I noticed
    switching the order of SPL / TPL has advantages.

    The "Tiny Program Loader" was mentioned first in this mail:
    https://lists.denx.de/pipermail/u-boot/2015-August/222900.html


4.  When Simon started to move CONFIG_TPL,
    I suggested it once again
    http://patchwork.ozlabs.org/patch/662396/



So, I'd like to make "TPL -> SPL" legitimate.


More ideally, I hope this is done outside of luxury frameworks.
No DM, no OF_CONTROL, then CONFIG_TPL_* are all gone.






-- 
Best Regards
Masahiro Yamada