[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Wei Xu]

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>;
 	};
 
 	cpus {
-- 
1.8.1.2

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Arnd Bergmann]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Wei Xu]

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
> 
> .
> 

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Arnd Bergmann]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Wei Xu]

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
> 
> .
> 

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Alexander Graf]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Arnd Bergmann]

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] ARM: dts: hip04: move bootwrapper to SRAM

[Mark Rutland]

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.

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Alexander Graf]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Mark Rutland]

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.

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Arnd Bergmann]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Frediano Ziglio]

> 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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Arnd Bergmann]

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

[PATCH] ARM: dts: hip04: move bootwrapper to SRAM

[Frediano Ziglio]

> 
> 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