Hi Genodians
As mentioned in an earlier mail I'm currently enabling base-hw on the IoT gateway of CompuLab [1].
The used SoC is a iMX8mm, which is a bit different from the iMX8mq used on the EVK [2].
On a running Linux I used `memtool` to read register values.
In `src/bootstrap/spec/iot_gateway/platform.cc` I have changed the following things: - the values for the `regulator` registers - the register offsets and values for the ARM_PLL registers - the values of the IOMUX configuration
Now the code bootstrap finishes and the kernel begins to run. By adding some `Genode::raw()`s to `void kernel_init()` I'm able to see, that the initialization for kernel waits for all CPUs to start at `while (!pool_ready) { ; }`.
If change `NR_OF_CPUS` to 1, I'm able to run the log run script.
log output of IoT gateway [1]:
``` Kernel: Board() :: 324 Kernel: Board() :: 342 Kernel: wake_up_all_cpus() :: 352 --- 1 Kernel: wake_up_all_cpus() :: 352 --- 2 Kernel: wake_up_all_cpus() :: 352 --- 3
Kernel: kernel_init() :: 56 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4
```
log output from EVK [2]:
``` Kernel: kernel_init() :: 56
Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 3 Kernel: initialize() :: 188 --- 3 initialized=3 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 2 Kernel: initialize() :: 188 --- 2 initialized=2 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 1 Kernel: initialize() :: 188 --- 1 initialized=1
kernel initialized
```
Has anybody an idea what registers could have an influence on the start up of the CPUs?
[1] https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm-...
[2] https://www.nxp.com/design/development-boards/i-mx-evaluation-and-developmen...
Best regards, Pirmin
Hello Pirmin,
On Tue, Oct 06, 2020 at 09:24:40AM +0200, Duss Pirmin wrote:
Hi Genodians
As mentioned in an earlier mail I'm currently enabling base-hw on the IoT gateway of CompuLab [1].
The used SoC is a iMX8mm, which is a bit different from the iMX8mq used on the EVK [2].
On a running Linux I used `memtool` to read register values.
In `src/bootstrap/spec/iot_gateway/platform.cc` I have changed the following things:
- the values for the `regulator` registers
- the register offsets and values for the ARM_PLL registers
- the values of the IOMUX configuration
Being in your position, I would not do PLL or IOMUX settings or whatever in the first place, but leave them out completely. Typically, the ARM Trusted Firmware and U-boot, which already run have configured the SoC in a way that you can use at least serial line, cpus and their timers. The addition of PLL settings for i.MX 8MQ were added when we wanted to raise the CPU frequency from the very beginning. The IOMUX settings are done here, because some more high-level peripherals like USB, Ethernet or display engine needed it. However they will be moved to the platform driver anyway. Anyway, to exclude that your settings influence the e.g., CPU frequency/voltage badly you should leave them out now.
The enabling of the secondary CPUs is done by the ARM Trusted Firmware in case of the i.MX8 MQ. As far as I can see by looking at the device tree of your SoC, it is the same for i.MX8 MM. Please, assure that Board::Cpu::wake_up_all_cpus() is doing the same, namely doing three SMC calls. You might check the result of the call!
Then please add raw() calls at the earliest place possible in bootstrap to see whether the secondary cpus may have come up, but stuck somewhere else. (when successful you will see character salad due to unsynchronized raw() calls).
I hope this helps somehow further.
Regards Stefan
Now the code bootstrap finishes and the kernel begins to run. By adding some `Genode::raw()`s to `void kernel_init()` I'm able to see, that the initialization for kernel waits for all CPUs to start at `while (!pool_ready) { ; }`.
If change `NR_OF_CPUS` to 1, I'm able to run the log run script.
log output of IoT gateway [1]:
Kernel: Board() :: 324 Kernel: Board() :: 342 Kernel: wake_up_all_cpus() :: 352 --- 1 Kernel: wake_up_all_cpus() :: 352 --- 2 Kernel: wake_up_all_cpus() :: 352 --- 3 Kernel: kernel_init() :: 56 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4log output from EVK [2]:
Kernel: kernel_init() :: 56 Kernel: initialize() :: 186 --- 0 Kernel: initialize() :: 188 --- 0 initialized=4 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 3 Kernel: initialize() :: 188 --- 3 initialized=3 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 2 Kernel: initialize() :: 188 --- 2 initialized=2 Kernel: initialize() :: 184 Kernel: initialize() :: 186 --- 1 Kernel: initialize() :: 188 --- 1 initialized=1 kernel initializedHas anybody an idea what registers could have an influence on the start up of the CPUs?
[1] https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm-...
[2] https://www.nxp.com/design/development-boards/i-mx-evaluation-and-developmen...
Best regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Stefan
Many thanks for the tips.
I have stripped out all code from Bootstrap::Platform::Boot::Boot() except of a Genode::raw() call. This is currently the first output I see from bootstrap.
I do now print print the value result after the asm call in wake_up_all_cpus(). The value of it is 0xfffffffffffffff7 for all 3 CPUs. This looks like an error to me, But I'm still trying to find the correct ARM/NXP manual that describes the 0xC4000003 register, so that I can understand what might go wrong.
Regards, Pirmin
Hi,
On Tue, Oct 06, 2020 at 01:24:44PM +0200, Duss Pirmin wrote:
Hello Stefan
Many thanks for the tips.
I have stripped out all code from Bootstrap::Platform::Boot::Boot() except of a Genode::raw() call. This is currently the first output I see from bootstrap.
I do now print print the value result after the asm call in wake_up_all_cpus(). The value of it is 0xfffffffffffffff7 for all 3 CPUs. This looks like an error to me, But I'm still trying to find the correct ARM/NXP manual that describes the 0xC4000003 register, so that I can understand what might go wrong.
The value 0xC4000003 is no register, but a SMC call [0] function identifier, and part of the Power State Coordination Interface [1]. So 0xfffffffffffffff7 seems to be -9, which means INVALID_ADDRESS according to [1]. Looks like the provided ip is not ok? It has to be in the RAM below 0x40000000, isn't it?
Regard Stefan
[0] https://static.docs.arm.com/den0028/c/DEN0028C-SMCCC-1.2_BET1.pdf [1] https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Inte...
Regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi,
On 06.10.20 13:44, Stefan Kalkowski wrote:
The value 0xC4000003 is no register, but a SMC call [0] function identifier, and part of the Power State Coordination Interface [1]. So 0xfffffffffffffff7 seems to be -9, which means INVALID_ADDRESS according to [1]. Looks like the provided ip is not ok? It has to be in the RAM below 0x40000000, isn't it?
I also had found the description for the PSCI and had started reading in it.
The address is indeed 0x4001003c. This parameter comes form the call in base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc where wake_up_all_cpus() is called with the address of _crt0_start_secondary.
How can I influence where a function is placed? I see, that in base/src/ld/genode.ld the content from crt0 is integrated.
Regards, Pirmin
Hi Pirmin,
On Tue, Oct 06, 2020 at 15:06:35 CEST, Duss Pirmin wrote:
How can I influence where a function is placed? I see, that in base/src/ld/genode.ld the content from crt0 is integrated.
A look at
https://github.com/genodelabs/genode/blob/master/tool/run/boot_dir/hw#L8-L22
may help further.
Greets
Hi Christian, Hi Stefan
On 06.10.20 15:25, Christian Helmuth wrote:
Hi Pirmin,
On Tue, Oct 06, 2020 at 15:06:35 CEST, Duss Pirmin wrote:
How can I influence where a function is placed? I see, that in base/src/ld/genode.ld the content from crt0 is integrated.
A look at
https://github.com/genodelabs/genode/blob/master/tool/run/boot_dir/hw#L8-L22
may help further.
Thanks this I have set to the same value as it is for EVK for my platform.
I have added the same debug messages to the bootstrap code for the EVK.
The address of ip is also 0x4001003c on this platform.
Best regards, Pirmin
Hi,
On Tue, Oct 06, 2020 at 03:06:35PM +0200, Duss Pirmin wrote:
Hi,
On 06.10.20 13:44, Stefan Kalkowski wrote:
The value 0xC4000003 is no register, but a SMC call [0] function identifier, and part of the Power State Coordination Interface [1]. So 0xfffffffffffffff7 seems to be -9, which means INVALID_ADDRESS according to [1]. Looks like the provided ip is not ok? It has to be in the RAM below 0x40000000, isn't it?
I also had found the description for the PSCI and had started reading in it.
The address is indeed 0x4001003c. This parameter comes form the call in base-hw/src/bootstrap/spec/arm_64/cortex_a53_mmu.cc where wake_up_all_cpus() is called with the address of _crt0_start_secondary.
sorry, for my misleading wrong sentence. I meant it has to be _not_ below 0x40000000. And I was refering to the ARM Trusted Firmware sources, I found are the right one for the i.MX 8MQ EVK. For your SoC, I found the line[0] to be the relevant one for the ip checking.
The question arises what version of the ATF are you using. Did you compiled the bootloader chain yourself?
Regards Stefan
[0] https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8mm/imx8...
How can I influence where a function is placed? I see, that in base/src/ld/genode.ld the content from crt0 is integrated.
Regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Stefan,
On 06/10/2020 16:18, Stefan Kalkowski wrote:
sorry, for my misleading wrong sentence. I meant it has to be _not_ below 0x40000000. And I was refering to the ARM Trusted Firmware sources, I found are the right one for the i.MX 8MQ EVK. For your SoC, I found the line[0] to be the relevant one for the ip checking.
The question arises what version of the ATF are you using. Did you compiled the bootloader chain yourself?
Yes, I have compiled the bootloader according to https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_r2.0/...
ATF is in the version rel_imx_5.4.24_2.1.0 plus some patches by compulab.
I will try It wit the version you have listed, and give feedback on how it went.
Regards, Primin
Hi Pirmin,
On Tue, Oct 06, 2020 at 06:13:36PM +0200, Pirmin Duss wrote:
Hi Stefan,
On 06/10/2020 16:18, Stefan Kalkowski wrote:
sorry, for my misleading wrong sentence. I meant it has to be _not_ below 0x40000000. And I was refering to the ARM Trusted Firmware sources, I found are the right one for the i.MX 8MQ EVK. For your SoC, I found the line[0] to be the relevant one for the ip checking.
The question arises what version of the ATF are you using. Did you compiled the bootloader chain yourself?
Yes, I have compiled the bootloader according to https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_r2.0/...
ATF is in the version rel_imx_5.4.24_2.1.0 plus some patches by compulab.
I will try It wit the version you have listed, and give feedback on how it went.
I did not wanted to encourage you to use another version for the ATF, but if you use other sources it would make more sense to look inside those to find out why you gain the result -9. So maybe you should use your compulab version for further investigation.
Regards Stefan
Regards, Primin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Stefan,
On 06/10/2020 18:29, Stefan Kalkowski wrote:
Hi Pirmin,
On Tue, Oct 06, 2020 at 06:13:36PM +0200, Pirmin Duss wrote:
Hi Stefan,
On 06/10/2020 16:18, Stefan Kalkowski wrote:
sorry, for my misleading wrong sentence. I meant it has to be _not_ below 0x40000000. And I was refering to the ARM Trusted Firmware sources, I found are the right one for the i.MX 8MQ EVK. For your SoC, I found the line[0] to be the relevant one for the ip checking.
The question arises what version of the ATF are you using. Did you compiled the bootloader chain yourself?
Yes, I have compiled the bootloader according to https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_r2.0/...
ATF is in the version rel_imx_5.4.24_2.1.0 plus some patches by compulab.
I will try It wit the version you have listed, and give feedback on how it went.
I did not wanted to encourage you to use another version for the ATF, but if you use other sources it would make more sense to look inside those to find out why you gain the result -9. So maybe you should use your compulab version for further investigation.
It also ocured to me, that I juts could look, what address the ATF of compulab uses. I just did this, and now log run works (for the record the address is 0x40200000).
Many thanks for your fast support.
Best regards, Pirmin
Hi Pirmin,
On Tue, Oct 06, 2020 at 06:34:02PM +0200, Pirmin Duss wrote:
Hi Stefan,
On 06/10/2020 18:29, Stefan Kalkowski wrote:
Hi Pirmin,
On Tue, Oct 06, 2020 at 06:13:36PM +0200, Pirmin Duss wrote:
Hi Stefan,
On 06/10/2020 16:18, Stefan Kalkowski wrote:
sorry, for my misleading wrong sentence. I meant it has to be _not_ below 0x40000000. And I was refering to the ARM Trusted Firmware sources, I found are the right one for the i.MX 8MQ EVK. For your SoC, I found the line[0] to be the relevant one for the ip checking.
The question arises what version of the ATF are you using. Did you compiled the bootloader chain yourself?
Yes, I have compiled the bootloader according to https://github.com/compulab-yokneam/meta-bsp-imx8mm/blob/iot-gate-imx8_r2.0/...
ATF is in the version rel_imx_5.4.24_2.1.0 plus some patches by compulab.
I will try It wit the version you have listed, and give feedback on how it went.
I did not wanted to encourage you to use another version for the ATF, but if you use other sources it would make more sense to look inside those to find out why you gain the result -9. So maybe you should use your compulab version for further investigation.
It also ocured to me, that I juts could look, what address the ATF of compulab uses. I just did this, and now log run works (for the record the address is 0x40200000).
Many thanks for your fast support.
nice that it works now. You're welcome!
Just out of curiosity: do you find out why their ATF restricts the entrypoint even inside the DDR memory?
Regards Stefan
Best regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hi Stefan,
On 07/10/2020 10:48, Stefan Kalkowski wrote:
nice that it works now. You're welcome!
Just out of curiosity: do you find out why their ATF restricts the entrypoint even inside the DDR memory?
I do not see a specific reason, this is the way it was created initially for the imx8mm by NXP.
Best regards, Pirmin
-
Christian Helmuth -
Duss Pirmin -
Pirmin Duss
-
Stefan Kalkowski