Hi Leo / all,

Sorry I'm coming to this a bit late as I was away for last 2 weeks.

On 9 April 2016 at 15:25, Leo Yan <leo.yan@linaro.org> wrote:
On Fri, Apr 08, 2016 at 02:04:57PM +0800, Shawn Guo wrote:
> On Fri, Apr 8, 2016 at 12:14 AM, Leo Yan <leo.yan@linaro.org> wrote:
> > On Thu, Apr 07, 2016 at 09:03:44AM -0700, John Stultz wrote:
>
> <snip>
>
> > > So is it just 4.1 that is having problems? And if so, how critical is
> > > it to have 4.1? I'm currently working to move the hikey AOSP side to
> > > 4.4, so I'd like to understand the need better so I can prioritize
> > > this issue.
> >
> > Now 4.1 has problem. There have no any output from uart0/3 after
> > uboot jump to kernel.
>
> I think there are two problems with hi6220-hikey.dts on 4.1 branch
> when booting with U-Boot.  Firstly, the 0x7400000 bytes memreserve at
> 0x0 is buggy, since we use reserved-memory node to reserve parts of
> that memory region.  We are fine with UEFI, because UEFI doesn't use
> /memreserve/ in DTB.  Secondly, the last 16MiB memory is marked as
> secured for TrustZone by ATF.  If kernel tries to use that section of
> memory, we will have problem.  U-Boot works around this by coding the
> physical memory size as 1024 - 16 = 1008 MiB.  So to get the kernel
> work with U-Boot, we only need to remove the  /memreserve/ line below
> from hi6220-hikey.dts.
>
> /memreserve/ 0x00000000 0x07400000;
>
> But a better change should be something like below, IMO.

Thanks for hints, Shawn. For 4.1's boot failure, it does related with
/memreserve/. Below two patches are to fix booting failure: one
patch is for kernel, I also think this patch can fix kernel 3.18's
issue. Another patch is to fix uboot so that kernel can see correct
info of memory regions:

Kernel's patch:

---8<---

>From 24a5e0152eea8d273b8679f61c155f30a077da06 Mon Sep 17 00:00:00 2001
From: Leo Yan <leo.yan@linaro.org>
Date: Sat, 9 Apr 2016 21:06:05 +0800
Subject: [PATCH] arm64: dts: polish reservation memory regions

Now in dts it combines /memreserve/ and reserved-memory two methods to
reserve memory regions; so finally it introduce panic which caused by
allocate zero page in early_init().

This will not introduce any issue when use UEFI, due EFI stub will
remove /memreserve/ from DTB; but it will work with u-boot. So polish
dts to use memory node to carve memory regions out.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 49 +++++++++++---------------
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 36d300f..5de8acb1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -7,8 +7,6 @@

 /dts-v1/;

-/memreserve/ 0x00000000 0x07400000;
-
 #include "hikey-pinctrl.dtsi"
 #include "hikey-gpio.dtsi"
 #include "hi6220.dtsi"
@@ -36,36 +34,29 @@
                linux,initrd-end = <0x0 0x0b600000>;
        };

-       memory {
+       /*
+        * Reserve below regions from memory node:
+        *
+        *  0x05e0,0000 - 0x05ef,ffff: MCU firmware runtime using
+        *  0x05f0,1000 - 0x05f0,1fff: Reboot reason
+        *  0x06df,f000 - 0x06df,ffff: Mailbox message data
+        *  0x0740,f000 - 0x0740,ffff: MCU firmware section
+        *  0x21f0,0000 - 0x21ff,ffff: pstore/ramoops buffer
+        *  0x3e00,0000 - 0x3fff,ffff: OP-TEE
+        */
+       memory@0 {
                device_type = "memory";
-               reg = <0x0 0x00000000 0x0 0x40000000>;
+               reg = <0x00000000 0x00000000 0x00000000 0x05e00000>,
+                     <0x00000000 0x05f00000 0x00000000 0x00001000>,
+                     <0x00000000 0x05f02000 0x00000000 0x00efd000>,
+                     <0x00000000 0x06e00000 0x00000000 0x0060f000>,
+                     <0x00000000 0x07410000 0x00000000 0x1aaf0000>,
+                     <0x00000000 0x22000000 0x00000000 0x1c000000>;
        };

-       reserved-memory {
-               #address-cells = <2>;
-               #size-cells = <2>;
-               ranges;
-
-               mcu-buf@05e00000 {
-                       no-map;
-                       reg = <0x0 0x05e00000 0x0 0x00100000>,  /* MCU firmware buffer */
-                             <0x0 0x0740f000 0x0 0x00001000>;  /* MCU firmware section */
-               };
-
-               reboot-reason@05f01000 {
-                       no-map;
-                       reg = <0x0 0x05f01000 0x0 0x00001000>;
-               };
-
-               mbox-buf@06dff000 {
-                       no-map;
-                       reg = <0x0 0x06dff000 0x0 0x00001000>;  /* Mailbox message buf */
-               };
-
-               pstore: pstore@0x21f00000 {
-                       no-map;
-                       reg = <0x0 0x21f00000 0x0 0x00100000>;  /* pstore/ramoops buffer */
-               };
+       pstore: pstore@0x21f00000 {
+               no-map;
+               reg = <0x0 0x21f00000 0x0 0x00100000>;  /* pstore/ramoops buffer */
        };

        ramoops {
--
1.9.1


Uboot's patch:

---8<---

>From ed5091a3f07d0b5c5bb0eece24aa24aa03523563 Mon Sep 17 00:00:00 2001
From: Leo Yan <leo.yan@linaro.org>
Date: Sat, 9 Apr 2016 22:03:08 +0800
Subject: [PATCH] arm: bootm-fdt.c: skip overwrite memory node for ARM64

Device tree is used to describe exactly hardware info. So we need make
sure all the hardware info including memory node should be correct in
the first place rather than overwrite by u-boot to automatically detect
memory size; otherwise if there have memory reservation info in original
dtb file, the function arch_fixup_fdt will overwrite the memory node and
kernel cannot know related info anymore.

Signed-off-by: Leo Yan <leo.yan@linaro.org>

Thanks for the patches, however I doubt this U-Boot patch will get accepted
by the upstream folks. I think what we will probably need to do is migrate
HiKey U-Boot over to using DT for its configuration.

I didn't do this in the original port, as there was very little HiKey DT in the
upstream kernel. Now that situation has changed over the last few kernel releases
we can import the DT into U-Boot and we will inherit all the memory nodes
etc which should hopefully fix the issue (if I've understood correctly). Unless
U-Boot is still buggy and overwrites the memory node of course ;)

This should also help with detecting if we are a 1gb/2gb board etc.

regards,

Peter.