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

[mark.rutland@arm.com (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.