| Message ID | 54B48D5E.6050902@hisilicon.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <xuwei5@hisilicon.com> > --- > arch/arm/boot/dts/hip04.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi > index 2388145..f0dfac7 100644 > --- a/arch/arm/boot/dts/hip04.dtsi > +++ b/arch/arm/boot/dts/hip04.dtsi > @@ -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
On 2015/1/13 16:33, Arnd Bergmann wrote: > 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 <xuwei5@hisilicon.com> >> --- >> arch/arm/boot/dts/hip04.dtsi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi >> index 2388145..f0dfac7 100644 >> --- a/arch/arm/boot/dts/hip04.dtsi >> +++ b/arch/arm/boot/dts/hip04.dtsi >> @@ -22,7 +22,7 @@ >> >> bootwrapper { >> compatible = "hisilicon,hip04-bootwrapper"; >> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; >> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; >> }; Hi Arnd, > 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 > > Arnd > > . >
On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: > On 2015/1/13 16:33, Arnd Bergmann wrote: > > 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 <xuwei5@hisilicon.com> > >> --- > >> arch/arm/boot/dts/hip04.dtsi | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi > >> index 2388145..f0dfac7 100644 > >> --- a/arch/arm/boot/dts/hip04.dtsi > >> +++ b/arch/arm/boot/dts/hip04.dtsi > >> @@ -22,7 +22,7 @@ > >> > >> bootwrapper { > >> compatible = "hisilicon,hip04-bootwrapper"; > >> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; > >> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; > >> }; > > Hi Arnd, > > > 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? 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
On 2015/1/13 17:02, Arnd Bergmann wrote: > On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: >> On 2015/1/13 16:33, Arnd Bergmann wrote: >>> 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 <xuwei5@hisilicon.com> >>>> --- >>>> arch/arm/boot/dts/hip04.dtsi | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi >>>> index 2388145..f0dfac7 100644 >>>> --- a/arch/arm/boot/dts/hip04.dtsi >>>> +++ b/arch/arm/boot/dts/hip04.dtsi >>>> @@ -22,7 +22,7 @@ >>>> >>>> bootwrapper { >>>> compatible = "hisilicon,hip04-bootwrapper"; >>>> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; >>>> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; >>>> }; >> >> Hi Arnd, >> >>> 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? Hi Arnd, > 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 > This unfortunately means that you will have to yet again publish > a firmware update image. > > Arnd > > . >
On 13.01.15 11:28, Wei Xu wrote: > > > On 2015/1/13 17:02, Arnd Bergmann wrote: >> On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: >>> On 2015/1/13 16:33, Arnd Bergmann wrote: >>>> 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 <xuwei5@hisilicon.com> >>>>> --- >>>>> arch/arm/boot/dts/hip04.dtsi | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi >>>>> index 2388145..f0dfac7 100644 >>>>> --- a/arch/arm/boot/dts/hip04.dtsi >>>>> +++ b/arch/arm/boot/dts/hip04.dtsi >>>>> @@ -22,7 +22,7 @@ >>>>> >>>>> bootwrapper { >>>>> compatible = "hisilicon,hip04-bootwrapper"; >>>>> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; >>>>> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; >>>>> }; >>> >>> Hi Arnd, >>> >>>> 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? > > Hi Arnd, > >> 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? 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
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
On Tuesday 13 January 2015 18:28:32 Wei Xu wrote: > > > 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? 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
> On Tuesday 13 January 2015 18:28:32 Wei Xu wrote: > > > > > 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? > > 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
On Tuesday 13 January 2015 14:18:16 Frediano Ziglio wrote: > > On Tuesday 13 January 2015 18:28:32 Wei Xu wrote: > > > > > > > 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? > > > > 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
On Tue, Jan 13, 2015 at 10:33:47AM +0000, Alexander Graf wrote: > > > On 13.01.15 11:28, Wei Xu wrote: > > > > > > On 2015/1/13 17:02, Arnd Bergmann wrote: > >> On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: > >>> On 2015/1/13 16:33, Arnd Bergmann wrote: > >>>> 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 <xuwei5@hisilicon.com> > >>>>> --- > >>>>> arch/arm/boot/dts/hip04.dtsi | 2 +- > >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>>> > >>>>> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi > >>>>> index 2388145..f0dfac7 100644 > >>>>> --- a/arch/arm/boot/dts/hip04.dtsi > >>>>> +++ b/arch/arm/boot/dts/hip04.dtsi > >>>>> @@ -22,7 +22,7 @@ > >>>>> > >>>>> bootwrapper { > >>>>> compatible = "hisilicon,hip04-bootwrapper"; > >>>>> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; > >>>>> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; > >>>>> }; > >>> > >>> Hi Arnd, > >>> > >>>> 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? > > > > Hi Arnd, > > > >> 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? > > 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.
On 01/14/15 11:51, Mark Rutland wrote: > On Tue, Jan 13, 2015 at 10:33:47AM +0000, Alexander Graf wrote: >> >> On 13.01.15 11:28, Wei Xu wrote: >>> >>> On 2015/1/13 17:02, Arnd Bergmann wrote: >>>> On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: >>>>> On 2015/1/13 16:33, Arnd Bergmann wrote: >>>>>> 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 <xuwei5@hisilicon.com> >>>>>>> --- >>>>>>> arch/arm/boot/dts/hip04.dtsi | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi >>>>>>> index 2388145..f0dfac7 100644 >>>>>>> --- a/arch/arm/boot/dts/hip04.dtsi >>>>>>> +++ b/arch/arm/boot/dts/hip04.dtsi >>>>>>> @@ -22,7 +22,7 @@ >>>>>>> >>>>>>> bootwrapper { >>>>>>> compatible = "hisilicon,hip04-bootwrapper"; >>>>>>> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; >>>>>>> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; >>>>>>> }; >>>>> Hi Arnd, >>>>> >>>>>> 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? >>> Hi Arnd, >>> >>>> 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? >> 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
On Wed, Jan 14, 2015 at 11:03:35AM +0000, Alexander Graf wrote: > On 01/14/15 11:51, Mark Rutland wrote: > > On Tue, Jan 13, 2015 at 10:33:47AM +0000, Alexander Graf wrote: > >> > >> On 13.01.15 11:28, Wei Xu wrote: > >>> > >>> On 2015/1/13 17:02, Arnd Bergmann wrote: > >>>> On Tuesday 13 January 2015 16:42:38 Wei Xu wrote: > >>>>> On 2015/1/13 16:33, Arnd Bergmann wrote: > >>>>>> 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 <xuwei5@hisilicon.com> > >>>>>>> --- > >>>>>>> arch/arm/boot/dts/hip04.dtsi | 2 +- > >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>>>>> > >>>>>>> diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi > >>>>>>> index 2388145..f0dfac7 100644 > >>>>>>> --- a/arch/arm/boot/dts/hip04.dtsi > >>>>>>> +++ b/arch/arm/boot/dts/hip04.dtsi > >>>>>>> @@ -22,7 +22,7 @@ > >>>>>>> > >>>>>>> bootwrapper { > >>>>>>> compatible = "hisilicon,hip04-bootwrapper"; > >>>>>>> - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; > >>>>>>> + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; > >>>>>>> }; > >>>>> Hi Arnd, > >>>>> > >>>>>> 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? > >>> Hi Arnd, > >>> > >>>> 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? > >> 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. 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. > 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.
> > On Tuesday 13 January 2015 14:18:16 Frediano Ziglio wrote: > > > On Tuesday 13 January 2015 18:28:32 Wei Xu wrote: > > > > > > > > > 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? > > > > > > 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 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
diff --git a/arch/arm/boot/dts/hip04.dtsi b/arch/arm/boot/dts/hip04.dtsi index 2388145..f0dfac7 100644 --- a/arch/arm/boot/dts/hip04.dtsi +++ b/arch/arm/boot/dts/hip04.dtsi @@ -22,7 +22,7 @@ bootwrapper { compatible = "hisilicon,hip04-bootwrapper"; - boot-method = <0x10c00000 0x10000>, <0xe0000100 0x1000>; + boot-method = <0xe00f0000 0x10000>, <0xe0000100 0x1000>; }; cpus {
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 <xuwei5@hisilicon.com> --- arch/arm/boot/dts/hip04.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)