The CPU freqs are not supposed to change before cpufreq policies
properly registered, meaning that they should be used to calculate the
initial CPU capacities.
Doing this helps choosing the best CPU during early boot, especially
for the initramfs decompressing.
Signed-off-by: Jeffy Chen <[email protected]>
---
When testing the rk3399-evb(arm64 big.LITTLE platform), i saw a noticable
slow-down in early boot:
[ 0.280176] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 3.564412] vcc_sys: supplied by dc_12v
[ 3.637176] iommu: Default domain type: Translated
[ 3.830721] SCSI subsystem initialized
That is because the big cores are running at a low freq(from bootrom), but
been chosen based on the larger initial cpu capacity.
drivers/base/arch_topology.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 1eb81f113786..d62fe1d4dda9 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -94,7 +94,7 @@ static void update_topology_flags_workfn(struct work_struct *work)
update_topology = 0;
}
-static u32 capacity_scale;
+static DEFINE_PER_CPU(u32, max_freq);
static u32 *raw_capacity;
static int free_raw_capacity(void)
@@ -108,16 +108,22 @@ static int free_raw_capacity(void)
void topology_normalize_cpu_scale(void)
{
u64 capacity;
+ u64 capacity_scale;
int cpu;
if (!raw_capacity)
return;
- pr_debug("cpu_capacity: capacity_scale=%u\n", capacity_scale);
+ capacity_scale = 1;
for_each_possible_cpu(cpu) {
- pr_debug("cpu_capacity: cpu=%d raw_capacity=%u\n",
- cpu, raw_capacity[cpu]);
- capacity = (raw_capacity[cpu] << SCHED_CAPACITY_SHIFT)
+ capacity = raw_capacity[cpu] * per_cpu(max_freq, cpu);
+ capacity_scale = max(capacity, capacity_scale);
+ }
+
+ pr_debug("cpu_capacity: capacity_scale=%llu\n", capacity_scale);
+ for_each_possible_cpu(cpu) {
+ capacity = raw_capacity[cpu] * per_cpu(max_freq, cpu);
+ capacity = (capacity << SCHED_CAPACITY_SHIFT)
/ capacity_scale;
topology_set_cpu_scale(cpu, capacity);
pr_debug("cpu_capacity: CPU%d cpu_capacity=%lu\n",
@@ -127,6 +133,7 @@ void topology_normalize_cpu_scale(void)
bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
{
+ struct clk *cpu_clk;
static bool cap_parsing_failed;
int ret;
u32 cpu_capacity;
@@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
return false;
}
}
- capacity_scale = max(cpu_capacity, capacity_scale);
raw_capacity[cpu] = cpu_capacity;
pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
cpu_node, raw_capacity[cpu]);
+
+ cpu_clk = of_clk_get(cpu_node, 0);
+ if (!PTR_ERR_OR_ZERO(cpu_clk))
+ per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
+
+ clk_put(cpu_clk);
} else {
if (raw_capacity) {
pr_err("cpu_capacity: missing %pOF raw capacity\n",
@@ -188,11 +200,8 @@ init_cpu_capacity_callback(struct notifier_block *nb,
cpumask_andnot(cpus_to_visit, cpus_to_visit, policy->related_cpus);
- for_each_cpu(cpu, policy->related_cpus) {
- raw_capacity[cpu] = topology_get_cpu_scale(cpu) *
- policy->cpuinfo.max_freq / 1000UL;
- capacity_scale = max(raw_capacity[cpu], capacity_scale);
- }
+ for_each_cpu(cpu, policy->related_cpus)
+ per_cpu(max_freq, cpu) = policy->cpuinfo.max_freq / 1000;
if (cpumask_empty(cpus_to_visit)) {
topology_normalize_cpu_scale();
--
2.11.0
On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
> The CPU freqs are not supposed to change before cpufreq policies
> properly registered, meaning that they should be used to calculate the
> initial CPU capacities.
>
> Doing this helps choosing the best CPU during early boot, especially
> for the initramfs decompressing.
>
> Signed-off-by: Jeffy Chen <[email protected]>
[...]
> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
> return false;
> }
> }
> - capacity_scale = max(cpu_capacity, capacity_scale);
> raw_capacity[cpu] = cpu_capacity;
> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
> cpu_node, raw_capacity[cpu]);
> +
> + cpu_clk = of_clk_get(cpu_node, 0);
> + if (!PTR_ERR_OR_ZERO(cpu_clk))
> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
> +
> + clk_put(cpu_clk);
I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
We have other non-clk mechanism for CPU DVFS and this needs to simply
use cpufreq APIs to get frequency value if required.
--
Regards,
Sudeep
On 2020-01-10 11:37 am, Sudeep Holla wrote:
> On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
>> The CPU freqs are not supposed to change before cpufreq policies
>> properly registered, meaning that they should be used to calculate the
>> initial CPU capacities.
>>
>> Doing this helps choosing the best CPU during early boot, especially
>> for the initramfs decompressing.
>>
>> Signed-off-by: Jeffy Chen <[email protected]>
>
> [...]
>
>> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
>> return false;
>> }
>> }
>> - capacity_scale = max(cpu_capacity, capacity_scale);
>> raw_capacity[cpu] = cpu_capacity;
>> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
>> cpu_node, raw_capacity[cpu]);
>> +
>> + cpu_clk = of_clk_get(cpu_node, 0);
>> + if (!PTR_ERR_OR_ZERO(cpu_clk))
>> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
>> +
>> + clk_put(cpu_clk);
>
> I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
> We have other non-clk mechanism for CPU DVFS and this needs to simply
> use cpufreq APIs to get frequency value if required.
...but in this case, as soon as cpufreq is ready the problem is gone
anyway, because it sees the big cluster's clock rate is way out-of-spec
and bumps it up to a sane OPP.
It really is unfortunate that so many RK3399 images out there are using
the broken firmware combination that manages to miss out the boot-time
PLL setup altogether.
Robin.
On 10/01/2020 12:37, Sudeep Holla wrote:
> On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
>> The CPU freqs are not supposed to change before cpufreq policies
>> properly registered, meaning that they should be used to calculate the
>> initial CPU capacities.
>>
>> Doing this helps choosing the best CPU during early boot, especially
>> for the initramfs decompressing.
>>
>> Signed-off-by: Jeffy Chen <[email protected]>
>
> [...]
>
>> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
>> return false;
>> }
>> }
>> - capacity_scale = max(cpu_capacity, capacity_scale);
>> raw_capacity[cpu] = cpu_capacity;
>> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
>> cpu_node, raw_capacity[cpu]);
>> +
>> + cpu_clk = of_clk_get(cpu_node, 0);
>> + if (!PTR_ERR_OR_ZERO(cpu_clk))
>> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
>> +
>> + clk_put(cpu_clk);
>
> I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
> We have other non-clk mechanism for CPU DVFS and this needs to simply
> use cpufreq APIs to get frequency value if required.
To support this, it's failing on my Arm64 Juno board.
...
[ 0.084858] CPU1 cpu_clk=-517
[ 0.087961] CPU2 cpu_clk=-517
[ 0.091005] CPU0 cpu_clk=-517
[ 0.094121] CPU3 cpu_clk=-517
[ 0.097248] CPU4 cpu_clk=-517
[ 0.100415] CPU5 cpu_clk=-517
...
Since you're on a big.LITTLE platform, did you specify
'capacity-dmips-mhz' for CPUs to be able to distinguish big and little
CPUs before CPUfreq kicks in?
$ grep capacity-dmips-mhz ./arch/arm64/boot/dts/arm/juno.dts
capacity-dmips-mhz = <1024>;
capacity-dmips-mhz = <1024>;
capacity-dmips-mhz = <578>;
capacity-dmips-mhz = <578>;
capacity-dmips-mhz = <578>;
capacity-dmips-mhz = <578>;
On 2020-01-10 12:01 pm, Dietmar Eggemann wrote:
> On 10/01/2020 12:37, Sudeep Holla wrote:
>> On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
>>> The CPU freqs are not supposed to change before cpufreq policies
>>> properly registered, meaning that they should be used to calculate the
>>> initial CPU capacities.
>>>
>>> Doing this helps choosing the best CPU during early boot, especially
>>> for the initramfs decompressing.
>>>
>>> Signed-off-by: Jeffy Chen <[email protected]>
>>
>> [...]
>>
>>> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
>>> return false;
>>> }
>>> }
>>> - capacity_scale = max(cpu_capacity, capacity_scale);
>>> raw_capacity[cpu] = cpu_capacity;
>>> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
>>> cpu_node, raw_capacity[cpu]);
>>> +
>>> + cpu_clk = of_clk_get(cpu_node, 0);
>>> + if (!PTR_ERR_OR_ZERO(cpu_clk))
>>> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
>>> +
>>> + clk_put(cpu_clk);
>>
>> I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
>> We have other non-clk mechanism for CPU DVFS and this needs to simply
>> use cpufreq APIs to get frequency value if required.
>
> To support this, it's failing on my Arm64 Juno board.
>
> ...
> [ 0.084858] CPU1 cpu_clk=-517
> [ 0.087961] CPU2 cpu_clk=-517
> [ 0.091005] CPU0 cpu_clk=-517
> [ 0.094121] CPU3 cpu_clk=-517
> [ 0.097248] CPU4 cpu_clk=-517
> [ 0.100415] CPU5 cpu_clk=-517
> ...
>
> Since you're on a big.LITTLE platform, did you specify
> 'capacity-dmips-mhz' for CPUs to be able to distinguish big and little
> CPUs before CPUfreq kicks in?
Indeed, and that's the "problem" - the capacities are there, but with
the broken firmware the kernel starts with the little (boot) cluster
clocked at either 400 or 200MHz, but the big cluster at just 12MHz. At
that speed, a full distro config can take about 3 minutes to get to the
point of loading cpufreq as a module, and I've seen at least one distro
reverting 97df3aa76b4a to 'fix' the symptom :(
Robin.
>
> $ grep capacity-dmips-mhz ./arch/arm64/boot/dts/arm/juno.dts
> capacity-dmips-mhz = <1024>;
> capacity-dmips-mhz = <1024>;
> capacity-dmips-mhz = <578>;
> capacity-dmips-mhz = <578>;
> capacity-dmips-mhz = <578>;
> capacity-dmips-mhz = <578>;
>
Hi Jeffy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on linux/master linus/master v5.5-rc5 next-20200108]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/arch_topology-Adjust-initial-CPU-capacities-with-current-freq/20200110-083308
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git adc92dd4550ee038a9794eae1c05d88721a3a737
config: riscv-rv32_defconfig (attached as .config)
compiler: riscv32-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <[email protected]>
All errors (new ones prefixed by >>):
drivers/base/arch_topology.o: In function `.L19':
>> arch_topology.c:(.text+0x1a2): undefined reference to `__udivdi3'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Hi Jeffy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on linux/master linus/master v5.5-rc5 next-20200109]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Jeffy-Chen/arch_topology-Adjust-initial-CPU-capacities-with-current-freq/20200110-083308
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git adc92dd4550ee038a9794eae1c05d88721a3a737
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <[email protected]>
All errors (new ones prefixed by >>):
drivers/base/arch_topology.o: In function `topology_normalize_cpu_scale.part.0':
>> arch_topology.c:(.text+0x224): undefined reference to `__aeabi_uldivmod'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/[email protected] Intel Corporation
Hi Robin,
Thanks for the clarification :)
On 01/10/2020 08:28 PM, Robin Murphy wrote:
> On 2020-01-10 12:01 pm, Dietmar Eggemann wrote:
>> On 10/01/2020 12:37, Sudeep Holla wrote:
>>> On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
>>>> The CPU freqs are not supposed to change before cpufreq policies
>>>> properly registered, meaning that they should be used to calculate the
>>>> initial CPU capacities.
>>>>
>>>> Doing this helps choosing the best CPU during early boot, especially
>>>> for the initramfs decompressing.
>>>>
>>>> Signed-off-by: Jeffy Chen <[email protected]>
>>>
>>> [...]
>>>
>>>> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct
>>>> device_node *cpu_node, int cpu)
>>>> return false;
>>>> }
>>>> }
>>>> - capacity_scale = max(cpu_capacity, capacity_scale);
>>>> raw_capacity[cpu] = cpu_capacity;
>>>> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
>>>> cpu_node, raw_capacity[cpu]);
>>>> +
>>>> + cpu_clk = of_clk_get(cpu_node, 0);
>>>> + if (!PTR_ERR_OR_ZERO(cpu_clk))
>>>> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
>>>> +
>>>> + clk_put(cpu_clk);
>>>
>>> I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
>>> We have other non-clk mechanism for CPU DVFS and this needs to simply
>>> use cpufreq APIs to get frequency value if required.
>>
>> To support this, it's failing on my Arm64 Juno board.
>>
>> ...
>> [ 0.084858] CPU1 cpu_clk=-517
>> [ 0.087961] CPU2 cpu_clk=-517
>> [ 0.091005] CPU0 cpu_clk=-517
>> [ 0.094121] CPU3 cpu_clk=-517
>> [ 0.097248] CPU4 cpu_clk=-517
>> [ 0.100415] CPU5 cpu_clk=-517
It there any other way to get the initial cpu capacity for this case?
Or can we just assuming all the cores running at the same freq here?
>> ...
>>
>> Since you're on a big.LITTLE platform, did you specify
>> 'capacity-dmips-mhz' for CPUs to be able to distinguish big and little
>> CPUs before CPUfreq kicks in?
>
> Indeed, and that's the "problem" - the capacities are there, but with
> the broken firmware the kernel starts with the little (boot) cluster
> clocked at either 400 or 200MHz, but the big cluster at just 12MHz. At
> that speed, a full distro config can take about 3 minutes to get to the
> point of loading cpufreq as a module, and I've seen at least one distro
> reverting 97df3aa76b4a to 'fix' the symptom :(
Right, for the big cluster, the bootrom(maskrom) will init the clock to
24MHz, and if the bootloader(u-boot for example) doesn't bump it, it
would become 12MHz after kernel initialized the whole clk tree.
And in rockchip's BSP 4.4 kernel, there are hacks to bump it to
800MHz(higher freq might require regulator changing) in clk tree
initialization, the BSP u-boot also added that recently.
The chromeos's coreboot looks fine, but upstream u-boot seems missing
that part too, i'll try to send a patch for that :)
>
> Robin.
>
>>
>> $ grep capacity-dmips-mhz ./arch/arm64/boot/dts/arm/juno.dts
>> capacity-dmips-mhz = <1024>;
>> capacity-dmips-mhz = <1024>;
>> capacity-dmips-mhz = <578>;
>> capacity-dmips-mhz = <578>;
>> capacity-dmips-mhz = <578>;
>> capacity-dmips-mhz = <578>;
>>
>
>
>
>
On 2020-01-11 2:51 am, JeffyChen wrote:
> Hi Robin,
>
> Thanks for the clarification :)
>
> On 01/10/2020 08:28 PM, Robin Murphy wrote:
>> On 2020-01-10 12:01 pm, Dietmar Eggemann wrote:
>>> On 10/01/2020 12:37, Sudeep Holla wrote:
>>>> On Thu, Jan 09, 2020 at 03:52:14PM +0800, Jeffy Chen wrote:
>>>>> The CPU freqs are not supposed to change before cpufreq policies
>>>>> properly registered, meaning that they should be used to calculate the
>>>>> initial CPU capacities.
>>>>>
>>>>> Doing this helps choosing the best CPU during early boot, especially
>>>>> for the initramfs decompressing.
>>>>>
>>>>> Signed-off-by: Jeffy Chen <[email protected]>
>>>>
>>>> [...]
>>>>
>>>>> @@ -146,10 +153,15 @@ bool __init topology_parse_cpu_capacity(struct
>>>>> device_node *cpu_node, int cpu)
>>>>> return false;
>>>>> }
>>>>> }
>>>>> - capacity_scale = max(cpu_capacity, capacity_scale);
>>>>> raw_capacity[cpu] = cpu_capacity;
>>>>> pr_debug("cpu_capacity: %pOF cpu_capacity=%u (raw)\n",
>>>>> cpu_node, raw_capacity[cpu]);
>>>>> +
>>>>> + cpu_clk = of_clk_get(cpu_node, 0);
>>>>> + if (!PTR_ERR_OR_ZERO(cpu_clk))
>>>>> + per_cpu(max_freq, cpu) = clk_get_rate(cpu_clk) / 1000;
>>>>> +
>>>>> + clk_put(cpu_clk);
>>>>
>>>> I don't like to assume DVFS to be supplied only using 'clk'. So NACK!
>>>> We have other non-clk mechanism for CPU DVFS and this needs to simply
>>>> use cpufreq APIs to get frequency value if required.
>>>
>>> To support this, it's failing on my Arm64 Juno board.
>>>
>>> ...
>>> [ 0.084858] CPU1 cpu_clk=-517
>>> [ 0.087961] CPU2 cpu_clk=-517
>>> [ 0.091005] CPU0 cpu_clk=-517
>>> [ 0.094121] CPU3 cpu_clk=-517
>>> [ 0.097248] CPU4 cpu_clk=-517
>>> [ 0.100415] CPU5 cpu_clk=-517
>
> It there any other way to get the initial cpu capacity for this case?
>
> Or can we just assuming all the cores running at the same freq here?
>
>>> ...
>>>
>>> Since you're on a big.LITTLE platform, did you specify
>>> 'capacity-dmips-mhz' for CPUs to be able to distinguish big and little
>>> CPUs before CPUfreq kicks in?
>>
>> Indeed, and that's the "problem" - the capacities are there, but with
>> the broken firmware the kernel starts with the little (boot) cluster
>> clocked at either 400 or 200MHz, but the big cluster at just 12MHz. At
>> that speed, a full distro config can take about 3 minutes to get to the
>> point of loading cpufreq as a module, and I've seen at least one distro
>> reverting 97df3aa76b4a to 'fix' the symptom :(
>
> Right, for the big cluster, the bootrom(maskrom) will init the clock to
> 24MHz, and if the bootloader(u-boot for example) doesn't bump it, it
> would become 12MHz after kernel initialized the whole clk tree.
>
> And in rockchip's BSP 4.4 kernel, there are hacks to bump it to
> 800MHz(higher freq might require regulator changing) in clk tree
> initialization, the BSP u-boot also added that recently.
>
> The chromeos's coreboot looks fine, but upstream u-boot seems missing
> that part too, i'll try to send a patch for that :)
Actually, last time I looked both the BSP U-Boot and mainline do contain
equivalent code to initialise both PLLs to (IIRC) 600MHz and apparently
adjust a couple of other things set by the maskrom. The trap is that
mainline does it in the SPL - thus the unfortunately common combination
of using the upstream main stage with the miniloader ends up missing out
that step entirely. In comparison, I'm now using the full upstream
TPL/SPL flow on my RK3399 board (NanoPC-T4) and even a full generic
distro kernel is acceptably quick:
[ 2.315378] Trying to unpack rootfs image as initramfs...
[ 2.781747] Freeing initrd memory: 7316K
...
[ 4.239990] Freeing unused kernel memory: 1984K
[ 4.247829] Run /init as init process
Robin.
Hi Robin,
On 01/11/2020 11:12 PM, Robin Murphy wrote:
>>
>
> Actually, last time I looked both the BSP U-Boot and mainline do contain
> equivalent code to initialise both PLLs to (IIRC) 600MHz and apparently
> adjust a couple of other things set by the maskrom. The trap is that
> mainline does it in the SPL - thus the unfortunately common combination
> of using the upstream main stage with the miniloader ends up missing out
> that step entirely. In comparison, I'm now using the full upstream
> TPL/SPL flow on my RK3399 board (NanoPC-T4) and even a full generic
> distro kernel is acceptably quick:
>
> [ 2.315378] Trying to unpack rootfs image as initramfs...
> [ 2.781747] Freeing initrd memory: 7316K
> ...
> [ 4.239990] Freeing unused kernel memory: 1984K
> [ 4.247829] Run /init as init process
Oops, sorry for the noise, i've checked in the wrong u-boot code base...
Will ask miniloader team to check that, thanks :)
>
> Robin.