Masahiro,
> On 20 Sep 2017, at 19:34, Masahiro Yamada <yamada.masah...@socionext.com>
> wrote:
>
> 2017-09-20 23:37 GMT+09:00 Dr. Philipp Tomsich
> <philipp.toms...@theobroma-systems.com>:
>> Masahiro & Simon,
>>
>>> On 20 Sep 2017, at 15:49, Simon Glass <s...@chromium.org> wrote:
>>>
>>> Hi Masahiro,
>>>
>>> On 19 September 2017 at 20:51, Masahiro Yamada
>>> <yamada.masah...@socionext.com> wrote:
>>>> Hi Simon,
>>>>
>>>>
>>>> 2017-09-17 6:23 GMT+09:00 Simon Glass <s...@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
> I'd rather want to see:
> <something> -> SPL -> U-Boot full
I would agree, that the stage before the SPL could be chip-specific.
However, this is unlikely to happen quickly as some of the infrastructure
(e.g. OF_PLATDATA) would have to be easily available to this new TPL
framework.
> <something> is implemented in an ad-hoc way under board or soc directory.
> If the space is premium, there is no room for DM, DT-ctrl in the <something>.
>
> Then, remove the current TPL support.
>
>
>
> It was only some old freescale boards that used TPL,
> so I was expecting they would die out sooner or later.
>
> Recently, lion-rk3368_defconfig was added wit TPL.
>
> Other rk3368 boards do not enable TPL.
Other RK3368 boards do not have DRAM init support yet (they still use
the proprietary vendor blobs and then boot the full U-Boot stage). This
is gated by the resource availability on Rockchip’s end to add support
for those features of the DRAM controller that can not be tested on Lion.
> Why does that board need TPL?
The RK3368’s boot-ROM loads only 0x7000 bytes as its first stage and
requires this to (a) set up clocking and (b) initialise the DRAM controller.
The SPL-stage on the RK3368 then runs out of DRAM (still loaded by
the boot-ROM), but the size-limit is somewhat relaxed.
On the RK3368, we take the liberty of reusing as much framework code
as possible in the TPL (resulting in 21k binary) and using OF_PLATDATA:
the features reused include DM, DM_REGMAP, DM_SYSCON, DM_CLK,
DM_RAM and DM_TIMER. With this, we can both use the same drivers
as for SPL and full U-Boot and then have a SPL stage that does not rely
of OF_PLATDATA (but has full OF_CONTROL).
Note that TPL is required for most of the Rockchip boards, if we want to
do the DRAM initialisation in U-Boot… those chips that already have their
DRAM controller drivers merged, usually have a TPL stage (with the
exception of the RK3399, which supports 192kB for its first stage).
Regards,
Philipp.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
