ARM: dts: hip04: move bootwrapper to SRAM
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.
--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/hip04.dtsi +1 -1
@@ -22,7 +22,7 @@ bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; }; cpus {
Signature · 1 line
1.8.1.2
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 14 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 6 lines
arch/arm/boot/dts/hip04.dtsi +1
-1@@ -22,7 +22,7 @@ bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };
Is this backwards compatible with old firmware?
Arnd
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };
Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Thanks!
Best Regards,
Wei
Quoted 5 lines
Arnd
.
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 31 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
This unfortunately means that you will have to yet again publish a firmware update image.
Arnd
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 32 lines · Arnd Bergmann
Quoted 31 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Hi Arnd,
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).
Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
Best Regards,
Wei
Quoted 7 lines
This unfortunately means that you will have to yet again publish a firmware update image.
Arnd
.
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 50 lines · Wei Xu
Quoted 32 lines · Arnd Bergmann
Quoted 31 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Hi Arnd,
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
Quoted 8 lines
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The main problem is that on this platform, the device tree doesn't necessarily come from UEFI. If you boot using grub for example, you need to manually pass in the device tree as a file in your grub configuration, because 32bit ARM Linux doesn't have an EFI stub that fetches it directly from EFI.
The "real" solution to all of this would be proper PSCI calls, but I'd rather not be the one implementing all of the frameworks for it :). And I'm not it's worth the effort for a 32bit platform that basically works now with bootwrapper living in SRAM.
Alex
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 6 lines · On Tuesday 13 January 2015 11:33:47 Alexander Graf wrote:
The "real" solution to all of this would be proper PSCI calls, but I'd rather not be the one implementing all of the frameworks for it :). And I'm not it's worth the effort for a 32bit platform that basically works now with bootwrapper living in SRAM.
That would still leave the same problem, since we'd still need to deal with old firmware that does not have PSCI.
Arnd
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
In reply to Alexander GrafQuoted 59 lines · Alexander Graf
Quoted 56 lines · Wei Xu
Quoted 32 lines · Arnd Bergmann
Quoted 31 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Hi Arnd,
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).
Quoted 8 lines
Quoted 2 lines
Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The main problem is that on this platform, the device tree doesn't necessarily come from UEFI. If you boot using grub for example, you need to manually pass in the device tree as a file in your grub configuration, because 32bit ARM Linux doesn't have an EFI stub that fetches it directly from EFI.
For arm64, upstream GRUB can acquire a DTB from EFI by GUID and pass to a non EFI stub kernel. Is that not the case for 32-bit ARM?
Thanks,
Mark.
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 56 lines · Mark Rutland
Quoted 55 lines · Alexander Graf
Quoted 53 lines · Wei Xu
Quoted 30 lines · Arnd Bergmann
Quoted 29 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Hi Arnd,
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
Quoted 7 lines
Quoted 5 lines
The main problem is that on this platform, the device tree doesn't necessarily come from UEFI. If you boot using grub for example, you need to manually pass in the device tree as a file in your grub configuration, because 32bit ARM Linux doesn't have an EFI stub that fetches it directly from EFI.
For arm64, upstream GRUB can acquire a DTB from EFI by GUID and pass to a non EFI stub kernel. Is that not the case for 32-bit ARM?
When did that happen? At least in the code that I'm aware of, Linux acquires the DTB from EFI directly via GUID in the efi stub without involving grub.
But 32bit ARM doesn't have an EFI stub and I didn't see any code in Grub for 32bit ARM fetching the DTB either. Which IMHO is ok, this is the only platform I've seen using EFI on 32bit at all anyways.
Alex
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 62 lines · Alexander Graf
Quoted 61 lines · Mark Rutland
Quoted 60 lines · Alexander Graf
Quoted 45 lines · Wei Xu
Quoted 30 lines · Arnd Bergmann
Quoted 29 lines · On Tuesday 13 January 2015 16:42:38 Wei Xu wrote:
Quoted 16 lines · Arnd Bergmann
Quoted 15 lines · On Tuesday 13 January 2015 11:13:34 Wei Xu wrote:
There is 8MB SRAM in hip04.
Moving the bootwrapper into SRAM could avoid to worry about poking holes into DRAM memory or allocation algorithms either.Signed-off-by Wei Xu <[email protected]>--- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/arm/boot/dts/hip04.dtsi +0
-0@@ -22,7 +22,7 @@Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi line 26
Quoted 5 lines
arch/arm/boot/dts/hip04.dtsi +1
-1bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; };Hi Arnd,
Quoted 1 line
Is this backwards compatible with old firmware?
Sorry, it is not backwards compatible. Another reason is that it could support opensuse more smoothly.
Quoted 5 lines
Quoted 5 lines
I have updated the firmware and uploaded it into Linaro Hisilicon git tree last month. We will update the wiki on Linaro soon.
Do you think it is OK?
Hi Arnd,
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
Quoted 8 lines
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The main problem is that on this platform, the device tree doesn't necessarily come from UEFI. If you boot using grub for example, you need to manually pass in the device tree as a file in your grub configuration, because 32bit ARM Linux doesn't have an EFI stub that fetches it directly from EFI.
Quoted 6 lines
Quoted 2 lines
For arm64, upstream GRUB can acquire a DTB from EFI by GUID and pass to a non EFI stub kernel. Is that not the case for 32-bit ARM?
When did that happen? At least in the code that I'm aware of, Linux acquires the DTB from EFI directly via GUID in the efi stub without involving grub.
See grub-core/loader/arm64/linux.c. If the kernel doesn't have an EFI stub (e.g. if it's big-endian), GRUB will boot it as an Image rather than as an EFI application. In that case GRUB will look for a DTB by GUID in the tables provided by EFI, and pass this to the kernel Image.
Quoted 3 lines
But 32bit ARM doesn't have an EFI stub and I didn't see any code in Grub for 32bit ARM fetching the DTB either. Which IMHO is ok, this is the only platform I've seen using EFI on 32bit at all anyways.
Yeah, I couldn't spot DTB fetching in 32-bit GRUB either. IMO it should, otherwise a 32-bit filesystem with GRUB can only function one one platform, which goes against the major reason for anyone wanting EFI in the first place.
Thanks,
Mark.
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
In reply to Wei XuQuoted 8 lines · On Tuesday 13 January 2015 18:28:32 Wei Xu wrote:
Quoted 5 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
I very agreed with you.
Quoted 8 lines
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYP supporting PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The intention is certainly good. If you expect no further incompatible changes, how about adding another .dts file for this machine that can work with the old firmware?
Arnd
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 16 lines · On Tuesday 13 January 2015 18:28:32 Wei Xu wrote:
Quoted 6 lines
Quoted 5 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
Quoted 6 lines
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYPsupporting
Quoted 2 lines
PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).
Quoted 8 lines
Quoted 2 lines
Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The intention is certainly good. If you expect no further incompatible changes, how about adding another .dts file for this machine that can work with the old firmware?
Arnd
Would much prefer to have PSCI support instead directly in the firmware.
Frediano
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 16 lines · On Tuesday 13 January 2015 14:18:16 Frediano Ziglio wrote:
Quoted 16 lines · On Tuesday 13 January 2015 18:28:32 Wei Xu wrote:
Quoted 6 lines
Quoted 5 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a different place also update this property, if at all possible.
Quoted 6 lines
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYPsupporting
Quoted 2 lines
PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The intention is certainly good. If you expect no further incompatible changes, how about adding another .dts file for this machine that can work with the old firmware?
Would much prefer to have PSCI support instead directly in the firmware.
Makes sense, yes. Is there a timeline for how soon that can be done? If we can do it soon enough, we could simply skip this intermediate step but instead keep using the original dts with the old firmware and the future dts that advertises PSCI support, both in the kernel, but not a third one with the partially improved interface here.
Arnd
PATCH 1/1 ARM: dts: hip04: move bootwrapper to SRAM
Quoted 29 lines · On Tuesday 13 January 2015 14:18:16 Frediano Ziglio wrote:
Quoted 5 lines
Quoted 5 lines · On Tuesday 13 January 2015 18:28:32 Wei Xu wrote:
Quoted 4 lines
Quoted 4 lines
Generally speaking it's not ok to change firmware interfaces in an incompatible way. The preferred way to handle this would be to have the firmware that puts the boot wrapper into a
different
Quoted 11 lines
Quoted 11 lines
Quoted 8 lines
Quoted 1 line
place also update this property, if at all possible.
I very agreed with you.
But before we have two kind of firmwares one is boot from SVC supporting PXE/NAND/SATA/GRUB booting and the other is boot from HYP just supporting NAND booting.
This time we updated the firmware and made it boot from HYPsupporting
Quoted 2 lines
PXE/NAND/SATA/GRUB as we hoped(thanks for Alex's supporting!).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Since we have to publish a new firmware I think it is a chance to update the dts of kernel. How do you think about it?
The intention is certainly good. If you expect no further incompatible changes, how about adding another .dts file for this machine that can work with the old firmware?
Would much prefer to have PSCI support instead directly in the
firmware.
Quoted 7 lines
Makes sense, yes. Is there a timeline for how soon that can be done? If we can do it soon enough, we could simply skip this intermediate step but instead keep using the original dts with the old firmware and the future dts that advertises PSCI support, both in the kernel, but not a third one with the partially improved interface here.
Arnd
I finished updating boot wrapper for D01 to support PSCI and more changes. You can find at https://github.com/freddy77/bootwrapper/tree/psci.
This boot loader is expected to be loader at old (0x10c00000) location but it automatically move itself at 0xe00f0000 (code is position independent). This to be able to avoid memory reservation in the DTB file. The PSCI protocol support version 0.2 using smc instruction, I just removed boot wrapper specification in DTS and added
psci {
compatible = "arm,psci-0.2", "arm,psci";
method = "smc";
cpu_off = <0x84000002>;
cpu_on = <0x84000003>;
};(this setting is compatible with either version 0.1 or 0.2). Linux and Xen works correctly. It's so compatible with old and new versions of UEFI. Newer kernel should use PSCI and can safely overwrite initial memory (if bootwrapper is loaded at 0x10c00000). Old kernel will use boot wrapper at 0x10c00000 which is protected.
Some issues:
- does not protect memory in secure mode (not a regression, old code are placed into ram without protecting);
- SMC does not test reason (but cannot be called only by EL1/EL2 unless EL2 forbid, not hard to fix however);
- PSCI CPU_ON require that CPU is set to same exception level as caller. Actually it always set CPU in HYP mode (just discovered, not hard to fix);
- I was not able to stably turn off snoop in fabric leading the clusters partially on. Actually code to turn off snoop is commented out. Doing so I'm able to hot unplug and plug any number of CPUs.
Frediano