Dev December 2015

dev@lists.96boards.org

23 participants
15 discussions

by Geoff Levand

Just for anyone interested, I've been releasing experimental disk images of CoreOS [1] for the HiKey ARM64 developer board. These images currently have about 90% of the packages in the CoreOS developer build. See the README at https://github.com/glevand/hikey-coreos. [1] https://coreos.com/ -Geoff

8 years, 1 month

[ANN] HiKey mainline kernel based branch now available

by Guodong Xu

hello there, A new kernel branch for the HiKey is now available: hikey-mainline-rebase, which is now v4.4-rc3 based. That's a start (meaning there are issues), but topics and patches are keep coming. Goal here is to make HiKey finally land linus' tree. What’s new in this release? * Based on Linux kernel v4.4-rc3 * Debian Jessie developer image, with HDMI console. * patches are upstreaming targeted, and * managed by topic branches, for easy rebase to latest kernel * topics include: hikey-tracking-dts hikey-tracking-gpio hikey-tracking-pmic hikey-tracking-mmc hikey-tracking-wifi hikey-tracking-usb hikey-tracking-adv7511 hikey-tracking-drm hikey-tracking-pm What to expect in soon future? * topic on iommu, bt * new builds: Debian Jessie ALIP image * new builds: AOSP (Android M) * patches be accepted by mainline. Resources: For kernel source code, ref: https://github.com/96boards/linux/tree/hikey-mainline-rebase For download of Debian developer image, ref: https://builds.96boards.org/snapshots/hikey/community/hikey-mainline-rebase… For UEFI to use with this snapshots build, ref: https://builds.96boards.org/releases/hikey/linaro/binaries/15.11/ For documentation about everything of HiKey, please ref: https://github.com/96boards/documentation/wiki/HiKey Support & Bug Report: For general question or support request, please go to 96boards Community forum: https://www.96boards.org/forums/forum/products/hikey/ <https://www.96boards.org/dragonboard410c/forum> For any bug related to this release, please submit issues to the 96Boards Bug tracking system: https://bugs.96boards.org/enter_bug.cgi?product=HiKey Finally, to get in touch with us, you can also use IRC: #96boards on irc.freenode.net On behalf of the Linaro HiSilicon Landing team, cheers, Guodong

8 years, 3 months

kasan on db410c

by Pingbo Wen

Hi, Does anyone run KASan on db410c successfully? I merged arm64-upstream branch over integration-linux-qcomlt, and enable KASan feature, compiled with gcc 5.1. But the kernel hanged before start_kernel(), no log output. Please tell me if I miss something here. Pingbo

8 years, 3 months

Change kmalloc to vmalloc when loading firmware

by chenfeng

Hi, When memory is seriously fragmented.I can be failed while using kmalloc in loading firmware. Can we change it to vmalloc? Are there someone familiar with this module? No need to use use continuous memory, it may be fail when memory deeply fragmented. Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com> Signed-off-by: Xia Qing <saberlily.xia(a)hisilicon.com> --- drivers/base/firmware_class.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 8524450..ff8672d 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -257,7 +257,7 @@ static void __fw_free_buf(struct kref *ref) vunmap(buf->data); for (i = 0; i < buf->nr_pages; i++) __free_page(buf->pages[i]); - kfree(buf->pages); + vfree(buf->pages); } else #endif vfree(buf->data); @@ -660,7 +660,7 @@ static ssize_t firmware_loading_store(struct device *dev, if (!test_bit(FW_STATUS_DONE, &fw_buf->status)) { for (i = 0; i < fw_buf->nr_pages; i++) __free_page(fw_buf->pages[i]); - kfree(fw_buf->pages); + vfree(fw_buf->pages); fw_buf->pages = NULL; fw_buf->page_array_size = 0; fw_buf->nr_pages = 0; @@ -770,8 +770,7 @@ static int fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size) buf->page_array_size * 2); struct page **new_pages; - new_pages = kmalloc(new_array_size * sizeof(void *), - GFP_KERNEL); + new_pages = vmalloc(new_array_size * sizeof(void *)); if (!new_pages) { fw_load_abort(fw_priv); return -ENOMEM; @@ -780,7 +779,7 @@ static int fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size) buf->page_array_size * sizeof(void *)); memset(&new_pages[buf->page_array_size], 0, sizeof(void *) * (new_array_size - buf->page_array_size)); - kfree(buf->pages); + vfree(buf->pages); buf->pages = new_pages; buf->page_array_size = new_array_size; } https://lkml.org/lkml/2015/12/16/49

8 years, 3 months

Reference Software Platform 15.12 Release!

by Ricardo Salveti

We are happy to announce the 15.12 release for the reference software platform project! This is our second release and for the first time also including support for the Enterprise Edition. Since there is still no availability for the 96Boards HuskyBoard, the first EE RPB was produced using the current enterprise development boards that are available in Linaro, such as HiSilicon D02 and AMD Overdrive (same SoC from HuskyBoard, known as Seattle). Once HuskBoard is available, the work for making it supported by the EE RPB should be minimal. A lot of work was put in place for the EE RPB, covering firmware (UEFI/EDK2), Linux 4.4 (with ACPI), Debian Jessie/CentOS 7 network installers, OpenStack Liberty, Hadoop, Spark and a few others, consolidating the work from several other Linaro groups and teams as well as from community and members. For the Consumer Edition the CE AOSP RPB for Hikey is now using a 4.1 based kernel, closer to what is provided directly by AOSP. We decided to not push major updates and rebases for the CE Debian RPB kernel since we want the changes to follow the same kernel policy as used by the EE kernel (https://github.com/96boards/documentation/wiki/RP-Kernel-Policy). The goal of having one single tree for both CE and EE, with a strict upstream-based policy, will continue, and we hope to have more news on that in the upcoming weeks. The work for the CE OE/Yocto RPB was also started, but unfortunately not yet covering single 96boards machine (due lack of a common kernel). Please check https://github.com/96boards/meta-rpb and https://github.com/96boards/oe-rpb-manifest to see what is already done for OpenEmbedded. Highlights for this release: Enterprise Edition: - UEFI/EDK2 support for D02, provided by OpenPlatformPkg - 4.4-rc4 based kernel, including support for D02 and Overdrive - ACPI support for D02 and Overdrive (mandatory for the enterprise edition) - Debian 8.2 "Jessie" network installer (using the 4.4-rc4 based kernel). CentOS 7 network installer available in alpha state. - Components: * Docker 1.9.1 * OpenStack Liberty * ODPi BigTop (Hadoop, Spark, etc) * OpenJDK 8 Consumer Edition: CE Debian RPB for DragonBoard410 and HiKey (including support for the LeMaker version): - Debian 8.2 “Jessie” - 4.3 kernel (with additional patches) - OpenJDK 8 included by default - 96Boards artwork and default settings CE AOSP RPB for HiKey (including support for the LeMaker version): - AOSP Android Marshmallow 6.0 - 4.1 based kernel Install instructions, known issues, test reports and instructions to build from source are all published at https://github.com/96boards/documentation/wiki/RP-Release-2015.12. Please also check https://github.com/96boards/documentation/wiki/ReferenceSoftwareEE for documentation covering the components released as part of the EE RPB. For general questions or support requests, please go to the 96boards.org Community forum (https://www.96boards.org/forums/). For development questions and topics, please use the 96Boards.org development mailing-list (dev(a)lists.96boards.org). For bugs related to the 96Boards platforms, please use the 96Boards bug tracking system (https://bugs.96boards.org/). For bugs related to the reference software platform release, but on development boards that are not officially part of 96Boards, please use https://bugs.linaro.org instead (e.g. AMD Overdrive and HiSilicon D02). For IRC support, please go to the #96boards channel at Freenode. Challenges for the next release (15.03): - Add support for HiKey and Dragonboard410c at our common 96Boards kernel tree (by following https://github.com/96boards/documentation/wiki/RP-Kernel-Policy) - Extended support for CE OE/Yocto - Support for CE AOSP for Dragonboard410c (with freedreno) - Compliance process and check-list We hope you enjoy the release! On behalf of the Linaro 96Boards team, Ricardo Salveti

8 years, 4 months

[Questions]compressed kernel image in arm64

by chenfeng

Hi all, I found that the arm64 kernel doesn't support for compressed kernel image. In this way, the bootimage with android may be much bigger than compressed version. Who can tell the reason of this? I will be appreciated it! Feng,

8 years, 4 months

[RFC][PATCH] linaro-edk2: Enable "adb reboot bootloader" support

by John Stultz

This allows the bootloader to user a reserved page to read if the kernel requested we boot into fastboot mode or normal bootup. This allows users to reboot into fastboot mode w/o having to modify jumpers on J15 This change requires the kernel to support the communication of the reboot reason to the bootloader. I'm really not sure the method I'm using here is right (ie: setting a pointer to a physaddr and reading/writing to it). So any extra feedback or review would be appreciated! Cc: Vishal Bhoj <vishal.bhoj(a)linaro.org> Cc: haojian.zhuang(a)linaro.org Cc: guodong.xu(a)linaro.org Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- .../HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c | 26 ++++++++++++++++++++++ HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c | 1 + 2 files changed, 27 insertions(+) diff --git a/HisiPkg/HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c b/HisiPkg/HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c index 84fdea1..90507d2 100644 --- a/HisiPkg/HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c +++ b/HisiPkg/HiKeyPkg/Drivers/HiKeyDxe/InstallBootMenu.c @@ -375,6 +375,31 @@ HiKeyTestLed ( } } + +#define REBOOT_REASON_ADDR 0x05F01000 +#define REBOOT_REASON_BOOTLOADER 0x77665500 +#define REBOOT_REASON_NONE 0x77665501 +STATIC +VOID +EFIAPI +HiKeyDetectRebootReason ( + IN VOID + ) +{ + UINT32 *addr = (UINT32*)REBOOT_REASON_ADDR; + UINT32 val; + + val = *addr; + /* Check to see if "reboot booloader" was specified */ + if (val == REBOOT_REASON_BOOTLOADER) { + mBootIndex = 0; + } + /* Write NONE to the reason address to clear the state */ + *addr = REBOOT_REASON_NONE; + + return; +} + STATIC VOID EFIAPI @@ -540,6 +565,7 @@ HiKeyOnEndOfDxe ( } HiKeyDetectJumper (); + HiKeyDetectRebootReason (); // Check boot device. // If boot device is eMMC, it's always higher priority. diff --git a/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c b/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c index d7d15b5..e0ae73f 100644 --- a/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c +++ b/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c @@ -37,6 +37,7 @@ STATIC struct HiKeyReservedMemory { EFI_PHYSICAL_ADDRESS Size; } HiKeyReservedMemoryBuffer [] = { { 0x05E00000, 0x00100000 }, // MCU + { 0x05F01000, 0x00001000 }, // ADB REBOOT "REASON" { 0x06DFF000, 0x00001000 }, // MAILBOX { 0x0740F000, 0x00001000 }, // MAILBOX { 0x3E000000, 0x02000000 } // TEE OS -- 1.9.1

8 years, 4 months

[PATCH 1/2] firmware: Introduce reboot_reason driver

by John Stultz

This patch adds a basic driver to allow for commands like "reboot bootloader" and "reboot recovery" to communicate this reboot-reason to the bootloader. This is commonly done on Android devices, in order to reboot the device into fastboot or recovery mode. It also supports custom OEM specific commands, via "reboot oem-<value>". This driver pulls the phys memory address from DT as well as the magic reason values that are written to the address for each mode. Cc: Vishal Bhoj <vishal.bhoj(a)linaro.org> Cc: haojian.zhuang(a)linaro.org Cc: guodong.xu(a)linaro.org Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- drivers/firmware/Kconfig | 9 +++ drivers/firmware/Makefile | 1 + drivers/firmware/reboot_reason_sram.c | 107 ++++++++++++++++++++++++++++++++++ 3 files changed, 117 insertions(+) create mode 100644 drivers/firmware/reboot_reason_sram.c diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 6517132..de507b6 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -136,6 +136,15 @@ config QCOM_SCM bool depends on ARM || ARM64 +config REBOOT_REASON_SRAM + bool "Pass reboot reason to bootloader via SRAM" + default n + help + On many systems there is a desire to provide a reboot reason to + the bootloader, so that the bootloader can boot into a desired + mode on the next boot. This option enables support for communicating + this reason to the bootloader via SRAM + source "drivers/firmware/google/Kconfig" source "drivers/firmware/efi/Kconfig" diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 3fdd391..5e538bc 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT) += iscsi_ibft.o obj-$(CONFIG_FIRMWARE_MEMMAP) += memmap.o obj-$(CONFIG_QCOM_SCM) += qcom_scm.o CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1) +obj-$(CONFIG_REBOOT_REASON_SRAM)+= reboot_reason_sram.o obj-$(CONFIG_GOOGLE_FIRMWARE) += google/ obj-$(CONFIG_EFI) += efi/ diff --git a/drivers/firmware/reboot_reason_sram.c b/drivers/firmware/reboot_reason_sram.c new file mode 100644 index 0000000..af87b6d --- /dev/null +++ b/drivers/firmware/reboot_reason_sram.c @@ -0,0 +1,107 @@ +#include <linux/err.h> +#include <linux/io.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/interrupt.h> +#include <linux/spinlock.h> +#include <linux/reboot.h> + +/* Types of reasons */ +enum { + NONE, + BOOTLOADER, + RECOVERY, + OEM, + MAX_REASONS +}; + +static u32 reasons[MAX_REASONS]; +static void __iomem *reboot_reason_val_addr; +static struct notifier_block reboot_nb; + +static int reboot_reason(struct notifier_block *nb, unsigned long action, + void *data) +{ + char *cmd = (char *)data; + u32 reason = reasons[NONE]; + + if (!reboot_reason_val_addr) + return NOTIFY_DONE; + + if (cmd != NULL) { + if (!strncmp(cmd, "bootloader", 10)) + reason = reasons[BOOTLOADER]; + else if (!strncmp(cmd, "recovery", 8)) + reason = reasons[RECOVERY]; + else if (!strncmp(cmd, "oem-", 4)) { + unsigned long code; + + if (!kstrtoul(cmd+4, 0, &code)) + reason = reasons[OEM] | (code & 0xff); + } + } + + if (reason != -1) + writel(reason, reboot_reason_val_addr); + return NOTIFY_DONE; +} + +static int reboot_reason_probe(struct platform_device *pdev) +{ + struct resource *res; + u32 val; + int i; + + /* initialize the reasons */ + for (i = 0; i < MAX_REASONS; i++) + reasons[i] = -1; + + /* Try to grab the reason io address */ + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + reboot_reason_val_addr = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(reboot_reason_val_addr)) + return PTR_ERR(reboot_reason_val_addr); + + /* initialize specified reasons from DT */ + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val)) + reasons[NONE] = val; + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader", &val)) + reasons[BOOTLOADER] = val; + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", &val)) + reasons[RECOVERY] = val; + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", &val)) + reasons[OEM] = val; + + /* Install the notifier */ + reboot_nb.notifier_call = reboot_reason; + reboot_nb.priority = 256; + if (register_reboot_notifier(&reboot_nb)) { + dev_err(&pdev->dev, + "failed to setup restart handler.\n"); + } + return 0; +} + +int reboot_reason_remove(struct platform_device *pdev) +{ + unregister_reboot_notifier(&reboot_nb); + return 0; +} + +static const struct of_device_id reboot_reason_of_match[] = { + { .compatible = "linux,reboot-reason-sram", }, + { }, +}; +MODULE_DEVICE_TABLE(of, reboot_reason_of_match); + +static struct platform_driver reboot_reason_driver = { + .driver = { + .name = "reboot-reason-sram", + .of_match_table = reboot_reason_of_match, + }, + .probe = reboot_reason_probe, + .remove = reboot_reason_remove, +}; +module_platform_driver(reboot_reason_driver); -- 1.9.1

8 years, 4 months

Board recovery fail: stuck in TEE-CORE init

by Kevin Hilman

Trying to update firmware on a hikey that was previously running u-boot just fine, I followed the "Board Recovery" section of the Getting Started page[1], but end up with the init sequence getting stuck in TEE-CORE init (console log below[2]) Any ideas what's going wrong? I'm trying to update the firmware so I get serial output on the UART board. I'm currently only using the UART pins on the main board. Kevin [1] https://github.com/96boards/documentation/wiki/HiKeyGettingStarted#section-4 [2] debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1! Switch to aarch64 mode. CPU0 executes at 0xf9801000! INF TEE-CORE:init_primary_helper:322: Initializing (2f04385 #2 Sat Nov 28 10:50:14 UTC 2015 aarch64) INF TEE-CORE:init_teecore:81: teecore inits done

8 years, 4 months

KCFLAGS=-fno-pic with hikey-kernel

by chenfeng

Hi all, If you met the follow issue while booting hikey kernel. Synchronous Exception at 0x00000000374D0C30 Synchronous Exception at 0x00000000374D0C30 Synchronous Exception at 0x00000000374D0C30 Please add KCFLAGS=-fno-pic and try it again.

8 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev December 2015