Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version). I followed the steps of u-boot/board/hisilicon/hikey/README and everything is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Thanks, Liming Wang
1. https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
On 04/05/2016 09:51 AM, Liming Wang wrote:
Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version). I followed the steps of u-boot/board/hisilicon/hikey/README and everything is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Thanks, Liming Wang
https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
It seems to me that the console might not be properly setup for early printk. could you try one of these two settings please?
console=ttyAMA0,115200 earlycon=pl011,0xf8015000
or,
console=ttyAMA3,115200 earlycon=pl011,0xf7113000
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version). I followed the steps of u-boot/board/hisilicon/hikey/README and everything is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Thanks, Liming Wang
https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
It seems to me that the console might not be properly setup for early printk. could you try one of these two settings please?
Hi,
Thank you for your help, now early printk is OK and kernel prints something:
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016 [ 0.000000] CPU: AArch64 Processor [410fd033] revision 3 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] Early serial console at I/O port 0x0 (options '') [ 0.000000] bootconsole [uart0] enabled [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 128 MiB at 0x0000000036c00000 [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000] [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-linaro-hikey #1 [ 0.000000] Call trace: [ 0.000000] [<ffffffc0000886d8>] dump_backtrace+0x0/0x118 [ 0.000000] [<ffffffc000088800>] show_stack+0x10/0x20 [ 0.000000] [<ffffffc000807be4>] dump_stack+0x7c/0xc0 [ 0.000000] [<ffffffc000806378>] panic+0xd0/0x210 [ 0.000000] [<ffffffc000b30fa4>] memblock_alloc_base+0x2c/0x3c [ 0.000000] [<ffffffc000b30fc0>] memblock_alloc+0xc/0x18 [ 0.000000] [<ffffffc000b232b4>] early_alloc.constprop.1+0x14/0x4c [ 0.000000] [<ffffffc000b2349c>] __create_mapping+0x1b0/0x2b8 [ 0.000000] [<ffffffc000b236f0>] paging_init+0xf4/0x1a8 [ 0.000000] [<ffffffc000b2059c>] setup_arch+0x2a0/0x598 [ 0.000000] [<ffffffc000b1d664>] start_kernel+0x98/0x3b4 [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000]
It seems that kernel hangs at somewhere. After diggged the kernel, I found below commit triggers the panic:
commit 69005556c01cb7095d213be970010beeb27d1a22 Author: Leo Yan leo.yan@linaro.org Date: Fri Aug 7 11:40:37 2015 +0800
arm64: dts: add Hi6220 mailbox node
If I revert this commit, the kernel can boot to rootfs. Do you know why this commit can't work for booting kernel from u-boot? ( This kernel can boot from UEFI bootloader)
Another problem is that: after I revert above commit, the kernel boots successfully except multi cpus come online as follows:
[ 0.163734] EFI services will not be available. [ 1.248801] CPU1: failed to come online [ 2.269222] CPU2: failed to come online [ 3.289645] CPU3: failed to come online [ 4.310081] CPU4: failed to come online [ 5.330510] CPU5: failed to come online [ 6.350935] CPU6: failed to come online [ 7.371356] CPU7: failed to come online [ 7.375269] Brought up 1 CPUs [ 7.378265] SMP: Total of 1 processors activated.
I don't know whether this problem is related with above commit.
Thanks, Liming Wang
console=ttyAMA0,115200 earlycon=pl011,0xf8015000
or,
console=ttyAMA3,115200 earlycon=pl011,0xf7113000
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Hi Liming,
On Thu, Apr 07, 2016 at 12:45:56AM +0800, Liming Wang wrote:
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version). I followed the steps of u-boot/board/hisilicon/hikey/README and everything is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Thanks, Liming Wang
https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
It seems to me that the console might not be properly setup for early printk. could you try one of these two settings please?
Hi,
Thank you for your help, now early printk is OK and kernel prints something:
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016 [ 0.000000] CPU: AArch64 Processor [410fd033] revision 3 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] Early serial console at I/O port 0x0 (options '') [ 0.000000] bootconsole [uart0] enabled [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 128 MiB at 0x0000000036c00000 [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000] [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-linaro-hikey #1 [ 0.000000] Call trace: [ 0.000000] [<ffffffc0000886d8>] dump_backtrace+0x0/0x118 [ 0.000000] [<ffffffc000088800>] show_stack+0x10/0x20 [ 0.000000] [<ffffffc000807be4>] dump_stack+0x7c/0xc0 [ 0.000000] [<ffffffc000806378>] panic+0xd0/0x210 [ 0.000000] [<ffffffc000b30fa4>] memblock_alloc_base+0x2c/0x3c [ 0.000000] [<ffffffc000b30fc0>] memblock_alloc+0xc/0x18 [ 0.000000] [<ffffffc000b232b4>] early_alloc.constprop.1+0x14/0x4c [ 0.000000] [<ffffffc000b2349c>] __create_mapping+0x1b0/0x2b8 [ 0.000000] [<ffffffc000b236f0>] paging_init+0xf4/0x1a8 [ 0.000000] [<ffffffc000b2059c>] setup_arch+0x2a0/0x598 [ 0.000000] [<ffffffc000b1d664>] start_kernel+0x98/0x3b4 [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000]
It seems that kernel hangs at somewhere. After diggged the kernel, I found below commit triggers the panic:
commit 69005556c01cb7095d213be970010beeb27d1a22 Author: Leo Yan leo.yan@linaro.org Date: Fri Aug 7 11:40:37 2015 +0800
arm64: dts: add Hi6220 mailbox node
Which kernel are you using? You are using mainline kernel or 96boards kernel? Could you check if your code base has included below commit ID:
Author: Leo Yan leo.yan@linaro.org Date: Fri Oct 9 07:46:48 2015 +0800
arm64: dts: Reserve memory regions for hi6220
On Hi6220, below memory regions in DDR have specific purpose:
0x05e0,0000 - 0x05ef,ffff: For MCU firmware using at runtime; 0x06df,f000 - 0x06df,ffff: For mailbox message data; 0x0740,f000 - 0x0740,ffff: For MCU firmware's section; 0x3e00,0000 - 0x3fff,ffff: For OP-TEE.
This patch reserves these memory regions in DT.
Signed-off-by: Leo Yan leo.yan@linaro.org
If I revert this commit, the kernel can boot to rootfs. Do you know why this commit can't work for booting kernel from u-boot? ( This kernel can boot from UEFI bootloader)
Another problem is that: after I revert above commit, the kernel boots successfully except multi cpus come online as follows:
[ 0.163734] EFI services will not be available. [ 1.248801] CPU1: failed to come online [ 2.269222] CPU2: failed to come online [ 3.289645] CPU3: failed to come online [ 4.310081] CPU4: failed to come online [ 5.330510] CPU5: failed to come online [ 6.350935] CPU6: failed to come online [ 7.371356] CPU7: failed to come online [ 7.375269] Brought up 1 CPUs [ 7.378265] SMP: Total of 1 processors activated.
I don't know whether this problem is related with above commit.
I don't think it's related with above commit ID. Which ATF/UEFI you are using?
Thanks, Leo Yan
Thanks, Liming Wang
console=ttyAMA0,115200 earlycon=pl011,0xf8015000
or,
console=ttyAMA3,115200 earlycon=pl011,0xf7113000
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Thu, Apr 07, 2016 at 10:04:42AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 12:45:56AM +0800, Liming Wang wrote:
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
[...]
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016
Hi Liming,
BTW, I found you are using Linux kernel 3.18. So looks like you are using old kernel version with a new dtb file. I'm not sure if there have mismatching issue (such like PSCI and CPU node). Now we have moved Linux kernel to 4.1:
https://github.com/96boards/documentation/wiki/HiKey-RPB-Debian-Build-Source...
Thanks, Leo Yan
On Thu, Apr 07, 2016 at 10:04:42AM +0800, Leo Yan wrote:
Hi Liming,
On Thu, Apr 07, 2016 at 12:45:56AM +0800, Liming Wang wrote:
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
Hi all,
I'm trying to boot kernel with u-boot on a hikey board(lemaker version). I followed the steps of u-boot/board/hisilicon/hikey/README and everything is OK except the kernel hangs at "Starting kernel ..."
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Thanks, Liming Wang
https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
It seems to me that the console might not be properly setup for early printk. could you try one of these two settings please?
Hi,
Thank you for your help, now early printk is OK and kernel prints something:
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016 [ 0.000000] CPU: AArch64 Processor [410fd033] revision 3 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] Early serial console at I/O port 0x0 (options '') [ 0.000000] bootconsole [uart0] enabled [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] efi: UEFI not found. [ 0.000000] cma: Reserved 128 MiB at 0x0000000036c00000 [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000] [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-linaro-hikey #1 [ 0.000000] Call trace: [ 0.000000] [<ffffffc0000886d8>] dump_backtrace+0x0/0x118 [ 0.000000] [<ffffffc000088800>] show_stack+0x10/0x20 [ 0.000000] [<ffffffc000807be4>] dump_stack+0x7c/0xc0 [ 0.000000] [<ffffffc000806378>] panic+0xd0/0x210 [ 0.000000] [<ffffffc000b30fa4>] memblock_alloc_base+0x2c/0x3c [ 0.000000] [<ffffffc000b30fc0>] memblock_alloc+0xc/0x18 [ 0.000000] [<ffffffc000b232b4>] early_alloc.constprop.1+0x14/0x4c [ 0.000000] [<ffffffc000b2349c>] __create_mapping+0x1b0/0x2b8 [ 0.000000] [<ffffffc000b236f0>] paging_init+0xf4/0x1a8 [ 0.000000] [<ffffffc000b2059c>] setup_arch+0x2a0/0x598 [ 0.000000] [<ffffffc000b1d664>] start_kernel+0x98/0x3b4 [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x1000 bytes below 0x0. [ 0.000000]
It seems that kernel hangs at somewhere. After diggged the kernel, I found below commit triggers the panic:
commit 69005556c01cb7095d213be970010beeb27d1a22 Author: Leo Yan leo.yan@linaro.org Date: Fri Aug 7 11:40:37 2015 +0800
arm64: dts: add Hi6220 mailbox nodeWhich kernel are you using? You are using mainline kernel or 96boards
git://github.com/96boards/linux.git tag 96boards-hikey-15.05 git://github.com/96boards/linux.git tag 96boards-hikey-15.11
The first one boots OK and the second one failed to boot.
kernel? Could you check if your code base has included below commit ID:
Both kernel don't have the commit ID.
Author: Leo Yan leo.yan@linaro.org Date: Fri Oct 9 07:46:48 2015 +0800
arm64: dts: Reserve memory regions for hi6220
On Hi6220, below memory regions in DDR have specific purpose:
0x05e0,0000 - 0x05ef,ffff: For MCU firmware using at runtime; 0x06df,f000 - 0x06df,ffff: For mailbox message data; 0x0740,f000 - 0x0740,ffff: For MCU firmware's section; 0x3e00,0000 - 0x3fff,ffff: For OP-TEE.This patch reserves these memory regions in DT.
Signed-off-by: Leo Yan leo.yan@linaro.org
If I revert this commit, the kernel can boot to rootfs. Do you know why this commit can't work for booting kernel from u-boot? ( This kernel can boot from UEFI bootloader)
Another problem is that: after I revert above commit, the kernel boots successfully except multi cpus come online as follows:
[ 0.163734] EFI services will not be available. [ 1.248801] CPU1: failed to come online [ 2.269222] CPU2: failed to come online [ 3.289645] CPU3: failed to come online [ 4.310081] CPU4: failed to come online [ 5.330510] CPU5: failed to come online [ 6.350935] CPU6: failed to come online [ 7.371356] CPU7: failed to come online [ 7.375269] Brought up 1 CPUs [ 7.378265] SMP: Total of 1 processors activated.
I don't know whether this problem is related with above commit.
I don't think it's related with above commit ID. Which ATF/UEFI you are using?
I'm using ATF and u-boot. ATF is from git://github.com/96boards/arm-trusted-firmware.git. u-boot is from mainline u-boot: git://git.denx.de/u-boot.git
BR, Liming Wang
Thanks, Leo Yan
Thanks, Liming Wang
console=ttyAMA0,115200 earlycon=pl011,0xf8015000
or,
console=ttyAMA3,115200 earlycon=pl011,0xf7113000
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 10:04:42AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 12:45:56AM +0800, Liming Wang wrote:
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
[...]
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016
Hi Liming,
BTW, I found you are using Linux kernel 3.18. So looks like you are
Yes, I got the kernel from linaro:: https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
I think it's the latest.:)
using old kernel version with a new dtb file. I'm not sure if there have mismatching issue (such like PSCI and CPU node). Now we have moved Linux kernel to 4.1:
https://github.com/96boards/documentation/wiki/HiKey-RPB-Debian-Build-Source...
OK, I will try this kernel. Does 4.1 kernel support all features that 3.18 has supported? BTW, is there plan to move 4.4 kernel?
BR, Liming Wang
Thanks, Leo Yan
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 10:04:42AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 12:45:56AM +0800, Liming Wang wrote:
On Tue, Apr 05, 2016 at 03:33:38PM -0700, Jorge Ramirez-Ortiz wrote:
On 04/05/2016 09:51 AM, Liming Wang wrote:
[...]
I used the latest Image and hi6220-hikey.dtb from [1]. And boot log is attached. I don't know whether there is anything block the kernel to boot.
Starting kernel ...
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.18.0-linaro-hikey (buildslave@x86-64-08) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #1 SMP PREEMPT Thu Feb 25 07:17:29 UTC 2016
Hi Liming,
BTW, I found you are using Linux kernel 3.18. So looks like you are
Yes, I got the kernel from linaro:: https://builds.96boards.org/snapshots/hikey/linaro/debian/latest/
I think it's the latest.:)
Thanks for confirmation. I'm start to suspect the memory region passed from uboot is not same with UEFI. So when reserve memory nodes in mailbox's dts patch, it's out of the range of memory region which initalized in Kernel and finally introduce panic.
So for panic issue, UEFI will have no such issue, due UEFI will pass memory regions from EFI stub, so this panic will be only related with uboot's booting.
I will try at my side with uboot's booting as well.
using old kernel version with a new dtb file. I'm not sure if there have mismatching issue (such like PSCI and CPU node). Now we have moved Linux kernel to 4.1:
https://github.com/96boards/documentation/wiki/HiKey-RPB-Debian-Build-Source...
OK, I will try this kernel. Does 4.1 kernel support all features that 3.18 has supported?
Yes, please try 4.1, Let's work on the same code base firstly.
I think 4.1 kernel at least can resolve the issue for SMP booting. Please note, as you said in another email, 96baord's 15.05 version uses spin-table method rather than psci. So I think this is the reason for SMP booting's failure.
But like I said above, suppose the kernel version is not the root cause for memory region issue. If so please go back to report at here and it will be bug to be fixed.
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
Thanks, Leo Yan
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
Some updates for uboot booting on Hikey:
- I tried below images, which can boot successfully with uboot: ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: hikey-mainline-rebase
- If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
- I cannot reproduce Liming's panic;
- There have one potential issue for uboot. Uboot will overwrite dtb's memory node in the function *arch_fixup_fdt()*; so if we want to reserve memory regions in memory node, it doesn't work after the overwriting by uboot.
I will look into and try to fix it; If you have any suggestion let me know.
Thanks, Leo Yan
On Thu, Apr 7, 2016 at 11:02 PM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
Some updates for uboot booting on Hikey:
- I tried below images, which can boot successfully with uboot: ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: hikey-mainline-rebase
I also tried above combination and it can boot well. But it still has some issues: 1. multi cpus still can come online 2. The defconfig has no emmc support and doesn't detect the emmc. Could you share me with your kernel config against this branch? BTW: do you know what difference between branch 96b/releases/2016.03 and hikey-mainline-rebase? I found hikey-mainline-rebase is more stable than 96b/releases/2016.03 when booting with u-boot. For hikey-mainline-rebase, it can boot to mount initrd. And for 96b/releases/2016.03, it hangs at somewhere.
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
I cannot reproduce Liming's panic;
panic only happens on 3.18, just as mentioned in my first mail. You can try “https://github.com/96boards-hikey/linux tag 96boards-hikey-15.11"
- There have one potential issue for uboot. Uboot will overwrite dtb's
memory node in the function *arch_fixup_fdt()*; so if we want to reserve memory regions in memory node, it doesn't work after the overwriting by uboot.
I will look into and try to fix it; If you have any suggestion let me know.
OK, my current target is to boot 4.4 kernel with u-boot. Thank you for your great help.
BR, Liming Wang
Thanks, Leo Yan
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Also, I think there was a single patch against mainline needed to get hikey booting to a console(at least with UEFI), so you might even try with just that just to simplify the delta.
thanks -john
On Thu, Apr 7, 2016 at 8:59 AM, John Stultz john.stultz@linaro.org wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Oops. Sorry. Still drinking my coffee.
For some reason I thought the case you got working was with a 3.18 kernel, but it seems Guodong's mainline rebase tree already is working w/ uboot?
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.
thanks -john
On Thu, Apr 07, 2016 at 08:59:49AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Also, I think there was a single patch against mainline needed to get hikey booting to a console(at least with UEFI), so you might even try with just that just to simplify the delta.
Do you refer below Tyler's patch?
From a362ec8f677e5d701bc587edad93128897748c32 Mon Sep 17 00:00:00 2001
From: Tyler Baker tyler.baker@linaro.org Date: Wed, 30 Sep 2015 18:19:48 -0700 Subject: [PATCH] arm64: dts: add all hi6220 uart nodes
This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has been developed to standardize UART access across all the 96boards consumer edition boards. To use this hardware on HiKey we must configure and enable UART3. However, to ensure backward compatibility we must keep UART0 enabled as well.
I have removed the hard coded clock index values in favor of using the ones already defined in include/dt-bindings/clock/hi6220-clock.h.
Since UART0 needs to be soldered, it has been suggested to use the UART3 as the default console.
This patch was boot tested on top of next-20150930, with both UART configurations.
[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar
Signed-off-by: Tyler Baker tyler.baker@linaro.org Signed-off-by: Arnd Bergmann arnd@arndb.de --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 7 +++-- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 43 +++++++++++++++++++++++++- 2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index e36a539..8d43a0f 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts @@ -17,11 +17,14 @@ compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
aliases { - serial0 = &uart0; + serial0 = &uart0; /* On board UART0 */ + serial1 = &uart1; /* BT UART */ + serial2 = &uart2; /* LS Expansion UART0 */ + serial3 = &uart3; /* LS Expansion UART1 */ };
chosen { - stdout-path = "serial0:115200n8"; + stdout-path = "serial3:115200n8"; };
memory@0 { diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi index 3f03380..82d2488 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi @@ -5,6 +5,7 @@ */
#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/clock/hi6220-clock.h>
/ { compatible = "hisilicon,hi6220"; @@ -164,8 +165,48 @@ compatible = "arm,pl011", "arm,primecell"; reg = <0x0 0xf8015000 0x0 0x1000>; interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&ao_ctrl 36>, <&ao_ctrl 36>; + clocks = <&ao_ctrl HI6220_UART0_PCLK>, + <&ao_ctrl HI6220_UART0_PCLK>; clock-names = "uartclk", "apb_pclk"; }; + + uart1: uart@f7111000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0xf7111000 0x0 0x1000>; + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sys_ctrl HI6220_UART1_PCLK>, + <&sys_ctrl HI6220_UART1_PCLK>; + clock-names = "uartclk", "apb_pclk"; + status = "disabled"; + }; + + uart2: uart@f7112000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0xf7112000 0x0 0x1000>; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sys_ctrl HI6220_UART2_PCLK>, + <&sys_ctrl HI6220_UART2_PCLK>; + clock-names = "uartclk", "apb_pclk"; + status = "disabled"; + }; + + uart3: uart@f7113000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0xf7113000 0x0 0x1000>; + interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sys_ctrl HI6220_UART3_PCLK>, + <&sys_ctrl HI6220_UART3_PCLK>; + clock-names = "uartclk", "apb_pclk"; + }; + + uart4: uart@f7114000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x0 0xf7114000 0x0 0x1000>; + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sys_ctrl HI6220_UART4_PCLK>, + <&sys_ctrl HI6220_UART4_PCLK>; + clock-names = "uartclk", "apb_pclk"; + status = "disabled"; + }; }; };
On Thu, Apr 7, 2016 at 9:10 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 08:59:49AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Also, I think there was a single patch against mainline needed to get hikey booting to a console(at least with UEFI), so you might even try with just that just to simplify the delta.
Do you refer below Tyler's patch?
From a362ec8f677e5d701bc587edad93128897748c32 Mon Sep 17 00:00:00 2001 From: Tyler Baker tyler.baker@linaro.org Date: Wed, 30 Sep 2015 18:19:48 -0700 Subject: [PATCH] arm64: dts: add all hi6220 uart nodes
This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has been developed to standardize UART access across all the 96boards consumer edition boards. To use this hardware on HiKey we must configure and enable UART3. However, to ensure backward compatibility we must keep UART0 enabled as well.
Yes. Though I think there was also another one for mmc, but maybe that has since made it upstream?
thanks -john
On Thu, Apr 07, 2016 at 09:03:44AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 8:59 AM, John Stultz john.stultz@linaro.org wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Oops. Sorry. Still drinking my coffee.
For some reason I thought the case you got working was with a 3.18 kernel, but it seems Guodong's mainline rebase tree already is working w/ uboot?
Yes. Guodong's mainline rebase tree can works well.
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.
Thanks, Leo Yan
On Thu, Apr 7, 2016 at 9:13 AM, John Stultz john.stultz@linaro.org wrote:
On Thu, Apr 7, 2016 at 9:10 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 08:59:49AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Also, I think there was a single patch against mainline needed to get hikey booting to a console(at least with UEFI), so you might even try with just that just to simplify the delta.
Do you refer below Tyler's patch?
From a362ec8f677e5d701bc587edad93128897748c32 Mon Sep 17 00:00:00 2001 From: Tyler Baker tyler.baker@linaro.org Date: Wed, 30 Sep 2015 18:19:48 -0700 Subject: [PATCH] arm64: dts: add all hi6220 uart nodes
This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has been developed to standardize UART access across all the 96boards consumer edition boards. To use this hardware on HiKey we must configure and enable UART3. However, to ensure backward compatibility we must keep UART0 enabled as well.
Yes. Though I think there was also another one for mmc, but maybe that has since made it upstream?
So in an old tree, I have this patch from you Leo: "hi6220: enabled SD card and emmc", which adds regulator, pmic and dts entries. It looks like some of the regulator code landed in 4.6-rc but the rest seems to be missing still. So I suspect that would also be needed to boot off of anything but a ramdisk.
thanks -john
On Thu, Apr 7, 2016 at 9:14 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 09:03:44AM -0700, John Stultz wrote:
Oops. Sorry. Still drinking my coffee.
For some reason I thought the case you got working was with a 3.18 kernel, but it seems Guodong's mainline rebase tree already is working w/ uboot?
Yes. Guodong's mainline rebase tree can works well.
Good to hear.
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.
Hrm. Ok. And hikey on uboot is critical with 4.1?
thanks -john
On Thu, Apr 07, 2016 at 11:50:36PM +0800, Liming Wang wrote:
On Thu, Apr 7, 2016 at 11:02 PM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
Some updates for uboot booting on Hikey:
- I tried below images, which can boot successfully with uboot: ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: hikey-mainline-rebase
I also tried above combination and it can boot well. But it still has some issues:
- multi cpus still can come online
Can boot 8 cpus at my side.
- The defconfig has no emmc support and doesn't detect the emmc.
Could you share me with your kernel config against this branch? BTW: do you know what difference between branch 96b/releases/2016.03 and hikey-mainline-rebase? I found hikey-mainline-rebase is more stable than 96b/releases/2016.03 when booting with u-boot. For hikey-mainline-rebase, it can boot to mount initrd. And for 96b/releases/2016.03, it hangs at somewhere.
I can run into emmc's rootfs. Firstly burn filesystem as usual [1], Then directly use uboot's bootargs "root=/dev/mmcblk0p9", kernel can boot into rootfs. I don't use initrd.
[1] https://github.com/96boards/documentation/wiki/HiKey-RP-Download#your-build-...
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
I cannot reproduce Liming's panic;
panic only happens on 3.18, just as mentioned in my first mail. You can try “https://github.com/96boards-hikey/linux tag 96boards-hikey-15.11"
Like has a potential issue. Will first resolve uboot's overwritting dtb issue.
Thanks, Leo Yan
On Thu, Apr 07, 2016 at 09:19:28AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 9:13 AM, John Stultz john.stultz@linaro.org wrote:
On Thu, Apr 7, 2016 at 9:10 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 08:59:49AM -0700, John Stultz wrote:
On Thu, Apr 7, 2016 at 8:02 AM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
Hrm. I never did try booting hikey with uboot, so I don't have much to suggest.
As far as general suggestions, I'd probably try to focus on debugging w/ Guodong's currently 4.4 based mainline-rebase branch so you're closer to the upstream tree.
Also, I think there was a single patch against mainline needed to get hikey booting to a console(at least with UEFI), so you might even try with just that just to simplify the delta.
Do you refer below Tyler's patch?
From a362ec8f677e5d701bc587edad93128897748c32 Mon Sep 17 00:00:00 2001 From: Tyler Baker tyler.baker@linaro.org Date: Wed, 30 Sep 2015 18:19:48 -0700 Subject: [PATCH] arm64: dts: add all hi6220 uart nodes
This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has been developed to standardize UART access across all the 96boards consumer edition boards. To use this hardware on HiKey we must configure and enable UART3. However, to ensure backward compatibility we must keep UART0 enabled as well.
Yes. Though I think there was also another one for mmc, but maybe that has since made it upstream?
So in an old tree, I have this patch from you Leo: "hi6220: enabled SD card and emmc", which adds regulator, pmic and dts entries. It looks like some of the regulator code landed in 4.6-rc but the rest seems to be missing still. So I suspect that would also be needed to boot off of anything but a ramdisk.
Thanks for reminding. Will try to narrow down in tomorrow, or I can bisect delta patches :)
Thanks, Leo Yan
On Fri, Apr 08, 2016 at 12:28:08AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 11:50:36PM +0800, Liming Wang wrote:
On Thu, Apr 7, 2016 at 11:02 PM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
Some updates for uboot booting on Hikey:
- I tried below images, which can boot successfully with uboot: ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: hikey-mainline-rebase
I also tried above combination and it can boot well. But it still has some issues:
- multi cpus still can come online
sorry, should be "can't".
Can boot 8 cpus at my side.
- The defconfig has no emmc support and doesn't detect the emmc.
Could you share me with your kernel config against this branch? BTW: do you know what difference between branch 96b/releases/2016.03 and hikey-mainline-rebase? I found hikey-mainline-rebase is more stable than 96b/releases/2016.03 when booting with u-boot. For hikey-mainline-rebase, it can boot to mount initrd. And for 96b/releases/2016.03, it hangs at somewhere.
I can run into emmc's rootfs. Firstly burn filesystem as usual [1], Then directly use uboot's bootargs "root=/dev/mmcblk0p9", kernel can boot into rootfs. I don't use initrd.
I have burnt the rootfs before. But my compiled kernel against this branch failed to find the emmc and mmc. I just used defconfig and found defconfig doesn't enable CONFIG_MMC_DW_K3. Could you please share with me your defconfig, compiled kernel and dtb? Then I can try them to see whether they works at my side.
Thank you. Liming Wang
[1] https://github.com/96boards/documentation/wiki/HiKey-RP-Download#your-build-...
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
I cannot reproduce Liming's panic;
panic only happens on 3.18, just as mentioned in my first mail. You can try “https://github.com/96boards-hikey/linux tag 96boards-hikey-15.11"
Like has a potential issue. Will first resolve uboot's overwritting dtb issue.
Thanks, Leo Yan
On Fri, Apr 08, 2016 at 12:28:08AM +0800, Leo Yan wrote:
On Thu, Apr 07, 2016 at 11:50:36PM +0800, Liming Wang wrote:
On Thu, Apr 7, 2016 at 11:02 PM, Leo Yan leo.yan@linaro.org wrote:
On Thu, Apr 07, 2016 at 10:48:07AM +0530, Amit Kucheria wrote:
On Thu, Apr 07, 2016 at 12:24:58PM +0800, Liming Wang wrote:
On Thu, Apr 07, 2016 at 10:32:41AM +0800, Leo Yan wrote:
BTW, is there plan to move 4.4 kernel?
I think so. I'd like leave this question to John or Amit to answer.
The Reference Platform is already on 4.4 with the 16.03 release. So now we just need to make sure it works with u-boot. It was only tested with UEFI for 16.03 but u-boot-support is planned for 16.06.
Some updates for uboot booting on Hikey:
- I tried below images, which can boot successfully with uboot: ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: hikey-mainline-rebase
I also tried above combination and it can boot well. But it still has some issues:
- multi cpus still can come online
Can boot 8 cpus at my side.
- The defconfig has no emmc support and doesn't detect the emmc.
Could you share me with your kernel config against this branch? BTW: do you know what difference between branch 96b/releases/2016.03 and hikey-mainline-rebase? I found hikey-mainline-rebase is more stable than 96b/releases/2016.03 when booting with u-boot. For hikey-mainline-rebase, it can boot to mount initrd. And for 96b/releases/2016.03, it hangs at somewhere.
I can run into emmc's rootfs. Firstly burn filesystem as usual [1],
Hi,
Sorry, I just found there is hikey_defconfig. Using this config, rootfs can be mounted successfully now.
But the multi cpus still can't come onlie at my side. So would you please send me your config, compiled kernel and dtb to test?
Thanks, Liming Wang
Then directly use uboot's bootargs "root=/dev/mmcblk0p9", kernel can boot into rootfs. I don't use initrd.
[1] https://github.com/96boards/documentation/wiki/HiKey-RP-Download#your-build-...
If I change to use kernel branch 4.1 for android, then cannot boot:
ARM-TF: https://github.com/96boards/arm-trusted-firmware.git, branch: hikey U-BOOT: git://git.denx.de/u-boot.git KERNEL: https://github.com/96boards-hikey/linux; branch: android-hikey-linaro-4.1
When jump from uboot to kernel, there have no output. I also checked has enabled earlycon. So Amit, John, do you have any suggestion for this?
I cannot reproduce Liming's panic;
panic only happens on 3.18, just as mentioned in my first mail. You can try “https://github.com/96boards-hikey/linux tag 96boards-hikey-15.11"
Like has a potential issue. Will first resolve uboot's overwritting dtb issue.
Thanks, Leo Yan
Hi Liming,
On Fri, Apr 08, 2016 at 11:24:15AM +0800, Liming Wang wrote:
[...]
Hi,
Sorry, I just found there is hikey_defconfig. Using this config, rootfs can be mounted successfully now.
But the multi cpus still can't come onlie at my side. So would you please send me your config, compiled kernel and dtb to test?
I have shared my images into the folder: http://people.linaro.org/~leo.yan/binaries/hikey_uboot/
It includes boot images for l-loader.bin/fip.bin and kernel/dtb images. Also include kernel's config, I have not changed anything for kernel's config with using below command to build kernel:
make defconfig make -j8
Thanks, Leo Yan
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.
Shawn
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index 36d300f2aabd..0e95d7d297a6 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts @@ -7,7 +7,7 @@
/dts-v1/;
-/memreserve/ 0x00000000 0x07400000; +/memreserve/ 0x3f000000 0x01000000; /* Reserved 16MiB for TrustZone */
#include "hikey-pinctrl.dtsi" #include "hikey-gpio.dtsi"
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, Shawn. When developed on 4.1, we have not finalized the memory reservation in DTS. Now we have changed to use memory node to reserve memory nodes but not use neither /memreserve/ or reserved-memory [1].
So current issue is uboot overwrites memory node, we need find a general method to let uboot avoid (or skip) this step. If you have any suggestion for this, please let me know.
[1] http://archive.arm.linux.org.uk/lurker/message/20160121.105347.30a96332.en.h...
Thanks, Leo Yan
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index 36d300f2aabd..0e95d7d297a6 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts @@ -7,7 +7,7 @@
/dts-v1/;
-/memreserve/ 0x00000000 0x07400000; +/memreserve/ 0x3f000000 0x01000000; /* Reserved 16MiB for TrustZone */
#include "hikey-pinctrl.dtsi" #include "hikey-gpio.dtsi"
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 {
On Fri, Apr 08, 2016 at 01:07:58PM +0800, Leo Yan wrote:
Hi Liming,
On Fri, Apr 08, 2016 at 11:24:15AM +0800, Liming Wang wrote:
[...]
Hi,
Sorry, I just found there is hikey_defconfig. Using this config, rootfs can be mounted successfully now.
But the multi cpus still can't come onlie at my side. So would you please send me your config, compiled kernel and dtb to test?
I have shared my images into the folder: http://people.linaro.org/~leo.yan/binaries/hikey_uboot/
It includes boot images for l-loader.bin/fip.bin and kernel/dtb images. Also include kernel's config, I have not changed anything for kernel's config with using below command to build kernel:
Hi Leo,
I just found I used https://github.com/96boards/linux but you used https://github.com/96boards-hikey/linux. It's different, so which tree should I use to test?
After using https://github.com/96boards-hikey/linux, I could generate the same kernel config with yours, but generate a different dtb with yours. My tree's HEAD commit is below, please help me to confirm we used the same commit:
commit 41d0e8c16d18110718fbdc6cd8c1482100d077fb Merge: 1025574 ddf5088 Author: Guodong Xu guodong.xu@linaro.org Date: Thu Mar 17 21:32:32 2016 +0800
Merge remote-tracking branch 'linaro-android/test/linaro-android-4.4' into working-hikey-mainline-rebase-v4.4-c15
Then I tested your l-loader.bin/fip.bin and kernel/dtb images, and I found some issues:
1. Your dtb didn't fit my board, the kernel still panic. I have attached the log. If I replace with my generated dtb, the kernel worked well and multi cpus also could come online. So I wonder whether we use the same board. I used leMaker version, 1GB RAM and 8GB Flash.
2. I found multi cpus issue is not related to kernel, but u-boot. The key problem is that in u-boot README, it provides a old version mcuimage link: https://builds.96boards.org/releases/hikey/linaro/binaries/15.05/mcuimage.bi... We know there are two version mcuimages and above is old. With the old mcuimage, the kernel could have multi cpus issue. We should provide a patch to fix this link.
BR, Liming Wang
make defconfig make -j8
Thanks, Leo Yan
On Sun, Apr 10, 2016 at 12:17 PM, Liming Wang liming.wang@canonical.com wrote:
On Fri, Apr 08, 2016 at 01:07:58PM +0800, Leo Yan wrote:
Hi Liming,
On Fri, Apr 08, 2016 at 11:24:15AM +0800, Liming Wang wrote:
[...]
Hi,
Sorry, I just found there is hikey_defconfig. Using this config, rootfs can be mounted successfully now.
But the multi cpus still can't come onlie at my side. So would you please send me your config, compiled kernel and dtb to test?
I have shared my images into the folder: http://people.linaro.org/~leo.yan/binaries/hikey_uboot/
It includes boot images for l-loader.bin/fip.bin and kernel/dtb images. Also include kernel's config, I have not changed anything for kernel's config with using below command to build kernel:
Hi Leo,
I just found I used https://github.com/96boards/linux but you used https://github.com/96boards-hikey/linux. It's different, so which tree should I use to test?
https://github.com/96boards/linux is for the unified kernel tree, which is now on 4.4 (and the tree used by our reference builds).
https://github.com/96boards-hikey/linux is the tree used and maintained by the HiSilicon LT.
Cheers,
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>, /* MCUfirmware buffer */
<0x0 0x0740f000 0x0 0x00001000>; /* MCUfirmware section */
};reboot-reason@05f01000 {no-map;reg = <0x0 0x05f01000 0x0 0x00001000>;};mbox-buf@06dff000 {no-map;reg = <0x0 0x06dff000 0x0 0x00001000>; /* Mailboxmessage 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/ramoopsbuffer */ };
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.
Hi,
On 10 April 2016 at 16:17, Liming Wang liming.wang@canonical.com wrote:
Sorry, I just found there is hikey_defconfig. Using this config, rootfs can be mounted successfully now.
But the multi cpus still can't come onlie at my side. So would you please send me your config, compiled kernel and dtb to
test?
I have shared my images into the folder: http://people.linaro.org/~leo.yan/binaries/hikey_uboot/
It includes boot images for l-loader.bin/fip.bin and kernel/dtb images. Also include kernel's config, I have not changed anything for kernel's config with using below command to build kernel:
Hi Leo,
I just found I used https://github.com/96boards/linux but you used https://github.com/96boards-hikey/linux. It's different, so which tree should I use to test?
After using https://github.com/96boards-hikey/linux, I could generate the same kernel config with yours, but generate a different dtb with yours. My tree's HEAD commit is below, please help me to confirm we used the same commit:
commit 41d0e8c16d18110718fbdc6cd8c1482100d077fb Merge: 1025574 ddf5088 Author: Guodong Xu guodong.xu@linaro.org Date: Thu Mar 17 21:32:32 2016 +0800
Merge remote-tracking branch 'linaro-android/test/linaro-android-4.4'into working-hikey-mainline-rebase-v4.4-c15
Then I tested your l-loader.bin/fip.bin and kernel/dtb images, and I found some issues:
- Your dtb didn't fit my board, the kernel still panic. I have attached
the log. If I replace with my generated dtb, the kernel worked well and multi cpus also could come online. So I wonder whether we use the same board. I used leMaker version, 1GB RAM and 8GB Flash.
- I found multi cpus issue is not related to kernel, but u-boot. The key
problem is that in u-boot README, it provides a old version mcuimage link:
https://builds.96boards.org/releases/hikey/linaro/binaries/15.05/mcuimage.bi... We know there are two version mcuimages and above is old. With the old mcuimage, the kernel could have multi cpus issue. We should provide a patch to fix this link.
I can certainly send a patch to update the readme.
Is there a link which I can use which will always contain the latest mcuimage.bin?
Also does anyone know if there is a published changelog for these mcuimage.bin binaries? IIRC in the past an updated mcuimage.bin has effected the ability to halt the processors via JTAG (using OpenOCD) So knowing what changes between mcuimage.bin versions would be useful.
I must admit to being slightly overwhelmed by the various repos, branches etc mentioned in this email thread. It reminded me of our mission to reduce fragmentation ;)
regards,
Peter.
On Wed, Apr 13, 2016 at 08:40:08AM +0100, Peter Griffin wrote:
On 10 April 2016 at 16:17, Liming Wang liming.wang@canonical.com wrote:
[...]
Hi Leo,
I just found I used https://github.com/96boards/linux but you used https://github.com/96boards-hikey/linux. It's different, so which tree should I use to test?
After using https://github.com/96boards-hikey/linux, I could generate the same kernel config with yours, but generate a different dtb with yours. My tree's HEAD commit is below, please help me to confirm we used the same commit:
commit 41d0e8c16d18110718fbdc6cd8c1482100d077fb Merge: 1025574 ddf5088 Author: Guodong Xu guodong.xu@linaro.org Date: Thu Mar 17 21:32:32 2016 +0800
Merge remote-tracking branch 'linaro-android/test/linaro-android-4.4'into working-hikey-mainline-rebase-v4.4-c15
Then I tested your l-loader.bin/fip.bin and kernel/dtb images, and I found some issues:
- Your dtb didn't fit my board, the kernel still panic. I have attached
the log. If I replace with my generated dtb, the kernel worked well and multi cpus also could come online. So I wonder whether we use the same board. I used leMaker version, 1GB RAM and 8GB Flash.
- I found multi cpus issue is not related to kernel, but u-boot. The key
problem is that in u-boot README, it provides a old version mcuimage link:
https://builds.96boards.org/releases/hikey/linaro/binaries/15.05/mcuimage.bi... We know there are two version mcuimages and above is old. With the old mcuimage, the kernel could have multi cpus issue. We should provide a patch to fix this link.
I can certainly send a patch to update the readme.
Is there a link which I can use which will always contain the latest mcuimage.bin?
Also does anyone know if there is a published changelog for these mcuimage.bin binaries? IIRC in the past an updated mcuimage.bin has effected the ability to halt the processors via JTAG (using OpenOCD) So knowing what changes between mcuimage.bin versions would be useful.
Now we take mcuimage.bin as BL30 image, so integrate it into UEFI package: https://github.com/96boards/edk2.git, branch: origin/hikey; The file is: HisiPkg/HiKeyPkg/NonFree/mcuimage.bin
commit 83b92eb6907ae1e9b27c976b1d7c4053685d4b21 Author: Leo Yan leo.yan@linaro.org Date: Tue Jul 7 13:50:59 2015 +0800
HiKeyPkg: mcuimage: update new version
Update MCU firmware to new version mcuimage_b0211.bin.
Signed-off-by: Leo Yan leo.yan@linaro.org
I must admit to being slightly overwhelmed by the various repos, branches etc mentioned in this email thread. It reminded me of our mission to reduce fragmentation ;)
+1. BTW, I also found when boot my own kernel with latest UEFI, then need hack grub.cfs like below:
menuentry 'Custom Kernel' { search.fs_label rootfs root search.fs_label boot esp linux ($esp)/Image console=tty0 console=ttyAMA3,115200 root=/dev/mmcblk0p9 rootwait rw efi=noruntime devicetree ($esp)/hi6220-hikey.dtb }
In the page https://github.com/96boards/documentation/wiki/HiKeyUEFI, it suggests to set "root=/dev/disk/by-partlabel/system", but looks like it cannot work anymore.
I don't know what is formal usage. Loop in Haojian for this question.
Thanks, Leo Yan
regards,
Peter.
On Wed, Apr 13, 2016 at 08:07:23AM +0100, Peter Griffin wrote:
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>, /* MCUfirmware buffer */
<0x0 0x0740f000 0x0 0x00001000>; /* MCUfirmware section */
};reboot-reason@05f01000 {no-map;reg = <0x0 0x05f01000 0x0 0x00001000>;};mbox-buf@06dff000 {no-map;reg = <0x0 0x06dff000 0x0 0x00001000>; /* Mailboxmessage 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/ramoopsbuffer */ };
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 also don't think this is an accpetable patch :)
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 ;)
Now U-boot forces to overwrite memory node. Or maybe we can add code to detect if DTB has memory node, then directly return from the function arch_fixup_fdt so can skip overwriting flow?
This should also help with detecting if we are a 1gb/2gb board etc.
Could do this by setting cmdline's mem=XXX, so can remain intact for DTB? Finally we can only maintain DTB in only one place (in kernel).
Thanks, Leo Yan
On Wed, Apr 13, 2016 at 1:59 PM, Leo Yan leo.yan@linaro.org wrote:
On Wed, Apr 13, 2016 at 08:40:08AM +0100, Peter Griffin wrote:
I must admit to being slightly overwhelmed by the various repos, branches etc mentioned in this email thread. It reminded me of our mission to reduce fragmentation ;)
+1. BTW, I also found when boot my own kernel with latest UEFI, then need hack grub.cfs like below:
menuentry 'Custom Kernel' { search.fs_label rootfs root search.fs_label boot esp linux ($esp)/Image console=tty0 console=ttyAMA3,115200 root=/dev/mmcblk0p9 rootwait rw efi=noruntime devicetree ($esp)/hi6220-hikey.dtb }
In the page https://github.com/96boards/documentation/wiki/HiKeyUEFI, it suggests to set "root=/dev/disk/by-partlabel/system", but looks like it cannot work anymore.
Adding Robert, our technical writer.
We're supporting too many releases and there is not enough eyeballs on the old 3.18 and 4.1-based releases, IMO. Robert and I talked earlier this week about adding headers to some of the old docs, pointing users to newer releases and much-improved documentation to support those releases.
I hope people will move to the 4.4-based releases soon.
Regards, Amit
Hi Leo,
On 13 April 2016 at 09:42, Leo Yan leo.yan@linaro.org wrote:
On Wed, Apr 13, 2016 at 08:07:23AM +0100, Peter Griffin wrote:
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>, /* MCUfirmware buffer */
<0x0 0x0740f000 0x0 0x00001000>; /* MCUfirmware 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 also don't think this is an accpetable patch :)
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
I should have checked the upstream kernel before writing that....actually nothing has changed upstream in terms of HiKey DT. In v4.6-rc3 we still have no DT for pinmux, gpio, pmic, usb or sd/emmc. So it is not possible to convert HiKey U-Boot over to being fully configured via DT.
The 'out of the box' upstream kernel only enables cpu's, interrupts, timer, and some UARTs :( It looks like various drivers have been merged, but strangely none of the DT which enables them for the HiKey board.
I have done some patches which start the conversion to a DT U-Boot, but it can only configure the UART until some more DT lands in the upstream kernel (this works, but the other U-Boot drivers still have to rely on platform data for their configuration).
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 ;)
Now U-boot forces to overwrite memory node. Or maybe we can add code to detect if DTB has memory node, then directly return from the function arch_fixup_fdt so can skip overwriting flow?
Looking at this in more detail, I don't think we can change the implementation of arch_fixup_fdt() at all as it is used by many platforms and we will almost certainly break things.
U-Boot generates the memory DT node based on its view of the memory banks, and this is how it works on all architectures I've looked at (MIPS, x86, arm).
So I think if the memory has to be reserved in this way (via the memory node), the correct (although not pretty) way to do it will be for U-Boot to represent the dram banks as they are currently being described in your DT patch. That way the memory DT node will be correctly re-generated based on U-Boots view of the dram banks when booting the kernel. Something like this: -
diff --git a/board/hisilicon/hikey/hikey.c b/board/hisilicon/hikey/hikey.c index 3b484a9..8570972 100644 --- a/board/hisilicon/hikey/hikey.c +++ b/board/hisilicon/hikey/hikey.c @@ -71,6 +71,8 @@ U_BOOT_DEVICES(hi6220_gpios) = {
DECLARE_GLOBAL_DATA_PTR;
+#if !CONFIG_IS_ENABLED(OF_CONTROL) + static const struct pl01x_serial_platdata serial_platdata = { #if CONFIG_CONS_INDEX == 1 .base = HI6220_UART0_BASE, @@ -87,6 +89,7 @@ U_BOOT_DEVICE(hikey_seriala) = { .name = "serial_pl01x", .platdata = &serial_platdata, }; +#endif
static struct mm_region hikey_mem_map[] = { { @@ -407,8 +410,35 @@ int dram_init(void)
void dram_init_banksize(void) { + /* + * Reserve below regions from DT memory node (which gets generated + * by U-Boot from the dram banks before booting the kernel. + * + * 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 + */ + gd->bd->bi_dram[0].start = PHYS_SDRAM_1; - gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; + gd->bd->bi_dram[0].size = 0x05e00000; + + gd->bd->bi_dram[1].start = 0x05f00000; + gd->bd->bi_dram[1].size = 0x00001000; + + gd->bd->bi_dram[2].start = 0x05f02000; + gd->bd->bi_dram[2].size = 0x00efd000; + + gd->bd->bi_dram[3].start = 0x06e00000; + gd->bd->bi_dram[3].size = 0x0060f000; + + gd->bd->bi_dram[4].start = 0x07410000; + gd->bd->bi_dram[4].size = 0x1aaf0000; + + gd->bd->bi_dram[5].start = 0x22000000; + gd->bd->bi_dram[5].size = 0x1c000000; }
I have a couple of questions though: -
1) Why can't we use memreserve or reserved-memory properties for some of these (especially for things like reboot-reason / mbox buf)? I can understand there maybe reasons for reserving op-tee memory via the memory node, but I'm not so sure about some of the other reservations. FYI U-Boot already correctly handles memreserve regions found in the DT (e.g. it won't place a initrd, or fdt blob in a reserved region).
2) If we do have to have some/all memory carveout regions represented in the memory node, do we have to have these reserved regions spread throughout the memory map? It would be much tidier to have one chunk for example 64Mb which is reserved at the end of RAM. I guess the mcuimage is statically linked by hisilicon at the address currently reserved for it, but others like mbox-buf, reboot reason etc presumably could be moved?
This would be similar to how tegra U-Boot is operating (which is also taking the same approach as I have described here for overcoming this problem), and has some memory reserved for the secure monitor which is not described to the kernel DT memory node.
See
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
and in particular the comment here
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
This should also help with detecting if we are a 1gb/2gb board etc.
Could do this by setting cmdline's mem=XXX, so can remain intact for DTB? Finally we can only maintain DTB in only one place (in kernel).
I can certainly see why that would be preferable, but the U-Boot project seems to import copies of the DT from the kernel into the U-Boot tree. Also there can be some variation, as my HiKey U-Boot DT patches show for example the "arm,pl011" UART needs an extra <clock> DT property in U-Boot which isn't present in the kernel DT to work. So in short I'm not sure it is possible to only have it in one place.
This is one reason for wanting the DT to merge in the upstream kernel before importing and converting U-Boot to be configured from DT. That way we can ensure the DT bindings will match exactly for the hi6220 SoC devices.
regards,
Peter.
On Tue, Apr 19, 2016 at 3:43 PM, Peter Griffin peter.griffin@linaro.org wrote:
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
I should have checked the upstream kernel before writing that....actually nothing has changed upstream in terms of HiKey DT. In v4.6-rc3 we still have no DT for pinmux, gpio, pmic, usb or sd/emmc. So it is not possible to convert HiKey U-Boot over to being fully configured via DT.
The 'out of the box' upstream kernel only enables cpu's, interrupts, timer, and some UARTs :( It looks like various drivers have been merged, but strangely none of the DT which enables them for the HiKey board.
This should change in 4.7. The DT changes missed 4.6 for unfortunate reasons. Sadly, I still don't see the changes in today's linux-next. Guodong did your maintainer get his changes into arm-soc for-next branch?
I have done some patches which start the conversion to a DT U-Boot, but it can only configure the UART until some more DT lands in the upstream kernel (this works, but the other U-Boot drivers still have to rely on platform data for their configuration).
On 19 April 2016 at 18:58, Amit Kucheria amit.kucheria@linaro.org wrote:
On Tue, Apr 19, 2016 at 3:43 PM, Peter Griffin peter.griffin@linaro.org wrote:
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
I should have checked the upstream kernel before writing that....actually nothing has changed upstream in terms of HiKey DT. In v4.6-rc3 we still have no DT for pinmux, gpio, pmic, usb or sd/emmc. So it is not possible to convert HiKey U-Boot over to being fully configured via DT.
The 'out of the box' upstream kernel only enables cpu's, interrupts, timer, and some UARTs :( It looks like various drivers have been merged, but strangely none of the DT which enables them for the HiKey board.
This should change in 4.7. The DT changes missed 4.6 for unfortunate reasons. Sadly, I still don't see the changes in today's linux-next. Guodong did your maintainer get his changes into arm-soc for-next branch?
DTS pull request was sent on 16/April. Now waiting Arnd, Olof, Kevin to integrate.
-Guodong
I have done some patches which start the conversion to a DT U-Boot, but it can only configure the UART until some more DT lands in the upstream kernel (this works, but the other U-Boot drivers still have to rely on platform data for their configuration).
On Tue, Apr 19, 2016 at 11:13:42AM +0100, Peter Griffin wrote:
[...]
So I think if the memory has to be reserved in this way (via the memory node), the correct (although not pretty) way to do it will be for U-Boot to represent the dram banks as they are currently being described in your DT patch. That way the memory DT node will be correctly re-generated based on U-Boots view of the dram banks when booting the kernel. Something like this: -
diff --git a/board/hisilicon/hikey/hikey.c b/board/hisilicon/hikey/hikey.c index 3b484a9..8570972 100644 --- a/board/hisilicon/hikey/hikey.c +++ b/board/hisilicon/hikey/hikey.c @@ -71,6 +71,8 @@ U_BOOT_DEVICES(hi6220_gpios) = {
DECLARE_GLOBAL_DATA_PTR;
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
static const struct pl01x_serial_platdata serial_platdata = { #if CONFIG_CONS_INDEX == 1 .base = HI6220_UART0_BASE, @@ -87,6 +89,7 @@ U_BOOT_DEVICE(hikey_seriala) = { .name = "serial_pl01x", .platdata = &serial_platdata, }; +#endif
static struct mm_region hikey_mem_map[] = { { @@ -407,8 +410,35 @@ int dram_init(void)
void dram_init_banksize(void) {
/** Reserve below regions from DT memory node (which gets generated* by U-Boot from the dram banks before booting the kernel.** 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*/gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
gd->bd->bi_dram[0].size = 0x05e00000;gd->bd->bi_dram[1].start = 0x05f00000;gd->bd->bi_dram[1].size = 0x00001000;gd->bd->bi_dram[2].start = 0x05f02000;gd->bd->bi_dram[2].size = 0x00efd000;gd->bd->bi_dram[3].start = 0x06e00000;gd->bd->bi_dram[3].size = 0x0060f000;gd->bd->bi_dram[4].start = 0x07410000;gd->bd->bi_dram[4].size = 0x1aaf0000;gd->bd->bi_dram[5].start = 0x22000000;gd->bd->bi_dram[5].size = 0x1c000000;}
If so, then later if we need reserve more memory regions then we need maintain in 3 places: kernel's dts, uboot and uefi :(
I have a couple of questions though: -
- Why can't we use memreserve or reserved-memory properties for some of
these (especially for things like reboot-reason / mbox buf)? I can understand
By using memreserve, kernel will map the memory node as usual but just don't allocte it from memory block. So if later other driver module maps it, then that means mapping the reserved region twice. Mark reminded this will introduce cache alias issue [1].
For reserved-memory, actually EPAPR has not defined this node.
[1] http://archive.arm.linux.org.uk/lurker/message/20160118.154259.eebaf8cd.en.h... [2] http://archive.arm.linux.org.uk/lurker/message/20151105.161315.cc3c99f5.en.h...
there maybe reasons for reserving op-tee memory via the memory node, but I'm not so sure about some of the other reservations.
Due Hi6220 there have some hardcode to reserve some memory regions which used by MCU firmware, which is usually is used by power management related stuffs.
FYI U-Boot already correctly handles memreserve regions found in the DT (e.g. it won't place a initrd, or fdt blob in a reserved region).
Thanks for sharing this.
- If we do have to have some/all memory carveout regions represented in
the memory node, do we have to have these reserved regions spread throughout the memory map? It would be much tidier to have one chunk for example 64Mb which is reserved at the end of RAM. I guess the mcuimage is statically linked by hisilicon at the address currently reserved for it, but others like mbox-buf, reboot reason etc presumably could be moved?
mbox-buf also is used by MCU :)
MCU will reserve memory regions for itself code and data sections, but it also reserve mbox-buf which used to communicate message between CA53 and MCU.
This would be similar to how tegra U-Boot is operating (which is also taking the same approach as I have described here for overcoming this problem), and has some memory reserved for the secure monitor which is not described to the kernel DT memory node.
See
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
and in particular the comment here
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
This should also help with detecting if we are a 1gb/2gb board etc.
Could do this by setting cmdline's mem=XXX, so can remain intact for DTB? Finally we can only maintain DTB in only one place (in kernel).
I can certainly see why that would be preferable, but the U-Boot project seems to import copies of the DT from the kernel into the U-Boot tree. Also there can be some variation, as my HiKey U-Boot DT patches show for example the "arm,pl011" UART needs an extra <clock> DT property in U-Boot which isn't present in the kernel DT to work. So in short I'm not sure it is possible to only have it in one place.
So does U-boot also need use DT to initialize uart? If so, could we change DT documentation in kernel so can describe hardware properly?
This is one reason for wanting the DT to merge in the upstream kernel before importing and converting U-Boot to be configured from DT. That way we can ensure the DT bindings will match exactly for the hi6220 SoC devices.
From my understanding, DTB is a description for hardware. So it should
be consistent for one specific platform.
From ARMv8 acutally we have good chance to unify booting sequence (ARMv7
is hard to unify booting sequence due hardware have not been unified, some SoCs can directly run in secure world but some will switch to normal world).
So I checked Juno's code in U-boot; it uses your suggested method to carve out reserved memory from memory bank but not really use dtb's memory node.
Thanks, Leo Yan
On 13 April 2016 at 16:29, Leo Yan leo.yan@linaro.org wrote:
+1. BTW, I also found when boot my own kernel with latest UEFI, then need hack grub.cfs like below:
menuentry 'Custom Kernel' { search.fs_label rootfs root search.fs_label boot esp linux ($esp)/Image console=tty0 console=ttyAMA3,115200 root=/dev/mmcblk0p9 rootwait rw efi=noruntime devicetree ($esp)/hi6220-hikey.dtb }
In the page https://github.com/96boards/documentation/wiki/HiKeyUEFI, it suggests to set "root=/dev/disk/by-partlabel/system", but looks like it cannot work anymore.
I don't know what is formal usage. Loop in Haojian for this question.
I think that "initrd=" is missed in menuentry. I suggest to use all binaries from debian release 15.11 except for kernel. Since you're using your own kernel.
Regards Haojian
Hi Leo,
On 21 April 2016 at 21:20, Leo Yan leo.yan@linaro.org wrote:
On Tue, Apr 19, 2016 at 11:13:42AM +0100, Peter Griffin wrote:
[...]
So I think if the memory has to be reserved in this way (via the memory node), the correct (although not pretty) way to do it will be for U-Boot to represent the dram banks as they are currently being described in your DT patch. That way the
memory
DT node will be correctly re-generated based on U-Boots view of the dram
banks
when booting the kernel. Something like this: -
diff --git a/board/hisilicon/hikey/hikey.c
b/board/hisilicon/hikey/hikey.c
index 3b484a9..8570972 100644 --- a/board/hisilicon/hikey/hikey.c +++ b/board/hisilicon/hikey/hikey.c @@ -71,6 +71,8 @@ U_BOOT_DEVICES(hi6220_gpios) = {
DECLARE_GLOBAL_DATA_PTR;
+#if !CONFIG_IS_ENABLED(OF_CONTROL)
static const struct pl01x_serial_platdata serial_platdata = { #if CONFIG_CONS_INDEX == 1 .base = HI6220_UART0_BASE, @@ -87,6 +89,7 @@ U_BOOT_DEVICE(hikey_seriala) = { .name = "serial_pl01x", .platdata = &serial_platdata, }; +#endif
static struct mm_region hikey_mem_map[] = { { @@ -407,8 +410,35 @@ int dram_init(void)
void dram_init_banksize(void) {
/** Reserve below regions from DT memory node (which getsgenerated
* by U-Boot from the dram banks before booting the kernel.** 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*/gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
gd->bd->bi_dram[0].size = 0x05e00000;gd->bd->bi_dram[1].start = 0x05f00000;gd->bd->bi_dram[1].size = 0x00001000;gd->bd->bi_dram[2].start = 0x05f02000;gd->bd->bi_dram[2].size = 0x00efd000;gd->bd->bi_dram[3].start = 0x06e00000;gd->bd->bi_dram[3].size = 0x0060f000;gd->bd->bi_dram[4].start = 0x07410000;gd->bd->bi_dram[4].size = 0x1aaf0000;gd->bd->bi_dram[5].start = 0x22000000;gd->bd->bi_dram[5].size = 0x1c000000;}
If so, then later if we need reserve more memory regions then we need maintain in 3 places: kernel's dts, uboot and uefi :(
Yes it is definitely not ideal. Although if these locations are mainly dictated by the mcu firmware over which we have no control. Hopefully they won't change very often.
I have a couple of questions though: -
- Why can't we use memreserve or reserved-memory properties for some of
these (especially for things like reboot-reason / mbox buf)? I can understand
By using memreserve, kernel will map the memory node as usual but just don't allocte it from memory block. So if later other driver module maps it, then that means mapping the reserved region twice. Mark reminded this will introduce cache alias issue [1].
For reserved-memory, actually EPAPR has not defined this node.
[1] http://archive.arm.linux.org.uk/lurker/message/20160118.154259.eebaf8cd.en.h... [2] http://archive.arm.linux.org.uk/lurker/message/20151105.161315.cc3c99f5.en.h...
Thanks for the links, that was an interesting read and actually has implications for some of our ST co-processor / mailbox drivers that are being upstreamed, so thanks for sharing it :)
there maybe reasons for reserving op-tee memory via the memory node, but I'm not so sure about some of the other reservations.
Due Hi6220 there have some hardcode to reserve some memory regions which used by MCU firmware, which is usually is used by power management related stuffs.
FYI U-Boot already correctly handles memreserve regions found in the DT (e.g. it won't place a initrd, or fdt blob in a reserved region).
Thanks for sharing this.
- If we do have to have some/all memory carveout regions represented in
the memory node, do we have to have these reserved regions spread throughout the memory
map?
It would be much tidier to have one chunk for example 64Mb which is reserved at the end of RAM. I guess the mcuimage is statically linked by hisilicon at the address currently reserved for it, but others like mbox-buf, reboot reason etc presumably could be moved?
mbox-buf also is used by MCU :)
MCU will reserve memory regions for itself code and data sections, but it also reserve mbox-buf which used to communicate message between CA53 and MCU.
Ah OK.
This would be similar to how tegra U-Boot is operating (which is also taking the same approach as I have described here for overcoming this problem), and has some memory reserved for the secure monitor which is not described to the kernel DT memory node.
See
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
and in particular the comment here
http://git.denx.de/?p=u-boot.git%3Ba=blob%3Bf=arch/arm/mach-tegra/board2.c%3...
This should also help with detecting if we are a 1gb/2gb board etc.
Could do this by setting cmdline's mem=XXX, so can remain intact for DTB? Finally we can only maintain DTB in only one place (in kernel).
I can certainly see why that would be preferable, but the U-Boot project seems to import copies of the DT from the kernel into the U-Boot tree. Also there can be some variation, as my HiKey U-Boot DT patches show for example the "arm,pl011" UART needs an extra <clock> DT property in U-Boot which isn't present in the kernel DT to work. So in short I'm
not
sure it is possible to only have it in one place.
So does U-boot also need use DT to initialize uart? If so, could we change DT documentation in kernel so can describe hardware properly?
Upstream U-Boot currently doesn't, but when this set https://www.mail-archive.com/u-boot@lists.denx.de/msg210314.html gets merged it will. The plan would be to progressively move over so that all / most U-Boot drivers use DT for configuration.
This is one reason for wanting the DT to merge in the upstream kernel before importing and converting U-Boot to be configured from DT. That way we can ensure the DT bindings will match exactly for the hi6220 SoC devices.
From my understanding, DTB is a description for hardware. So it should be consistent for one specific platform.
Yes that is my understanding as well, I'm not sure why U-Boot has deviated from the kernel bindings in this case. Hopefully it will be the only DT difference and if we add a better clock driver into U-Boot we could probably eliminate the need for the extra property and be totally aligned. As most of the U-Boot driver / glue code is stuff I wrote, I can make the HiKey bindings match exactly to the kernel ones.
From ARMv8 acutally we have good chance to unify booting sequence (ARMv7 is hard to unify booting sequence due hardware have not been unified, some SoCs can directly run in secure world but some will switch to normal world).
So I checked Juno's code in U-boot; it uses your suggested method to carve out reserved memory from memory bank but not really use dtb's memory node.
By describing the carveout in the U-Boot memory banks, it ends up being described in the memory node from the kernels DT point of view, because as you discovered the memory node gets overwritten in arch_fixup_fdt() based on the dram_bank layout.
I sent a patch here: - https://www.mail-archive.com/u-boot@lists.denx.de/msg210319.html
Which adjusts the HiKey memory layout to be aligned with your patch (and what will become the mainline kernel memory node in v4.7 DT). I was unsure if it was the correct approach, but it has now been reviewed by Tom Rini the U-Boot maintainer. So if he is happy...so am I.
Also thanks for your help in diagnosing and debugging the issue :)
Regards,
Peter.
-
Amit Kucheria -
Guodong Xu -
Haojian Zhuang -
John Stultz -
Jorge Ramirez-Ortiz -
Leo Yan -
Liming Wang -
Peter Griffin -
Ricardo Salveti -
Shawn Guo