Masahiro,
On 20 Sep 2017, at 19:34, Masahiro Yamada yamada.masahiro@socionext.com wrote:
2017-09-20 23:37 GMT+09:00 Dr. Philipp Tomsich philipp.tomsich@theobroma-systems.com:
Masahiro & Simon,
On 20 Sep 2017, at 15:49, Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 19 September 2017 at 20:51, Masahiro Yamada yamada.masahiro@socionext.com wrote:
Hi Simon,
2017-09-17 6:23 GMT+09:00 Simon Glass sjg@chromium.org:
+menu "Logging"
+config LOG
bool "Enable logging support"helpThis enables support for logging of status and debug messages. Thesecan be displayed on the console, recorded in a memory buffer, ordiscarded if not needed. Logging supports various categories andlevels of severity.+config SPL_LOG
bool "Enable logging support in SPL"helpThis enables support for logging of status and debug messages. Thesecan be displayed on the console, recorded in a memory buffer, ordiscarded if not needed. Logging supports various categories andlevels 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.