Dev

dev@lists.96boards.org

241 discussions

[RFC-hikey][PATCH 0/2] Add pstore support to HiKey

by John Stultz

After Rob pointed out there's a non-ancient version of the devicetree bindings for pstore/ramoops, I figured it would be worth migrating over to using it. So this series adds pstore/ramoops support to hikey, and its much more tidy compared to the last patch for this. Would love any extra feedback and review. The reserved ramoops address is mostly chosen at random, and while the bootloader doesn't seen to clear that memory, I suspect we will need a change to make sure that memory is protected by the bootloader and UEFI applications don't scribble over it. So help there would be appreciated! thanks -john Cc: Rob Herring <rob.herring(a)linaro.org> Cc: Arnd Bergmann <arnd.bergmann(a)linaro.org> Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Vishal Bhoj <vishal.bhoj(a)linaro.org> Greg Hackmann (1): pstore-ram: add Device Tree bindings John Stultz (1): hikey: dts: Add pstore support for HiKey Documentation/ramoops.txt | 6 +- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 13 +++ arch/arm64/configs/hikey_defconfig | 7 ++ fs/pstore/ram.c | 114 ++++++++++++++++++++++++- 4 files changed, 134 insertions(+), 6 deletions(-) -- 1.9.1

10 years, 8 months

Re: [Dev] page size benchmark result

by Pingbo Wen

Hi, > 在 2015年12月31日，22:48，Arnd Bergmann <arnd(a)arndb.de> 写道： >> >>> So in case of 4K pages, the minimum amount of free memory is 3MB, and >>> almost always there are less than 8 MB free, . This is expected. >>> >>> In contrast, for the 64KB page case, we never have less than 512MB >>> RAM free, and it's usually between 512 and 520MB, which is very surprising >>> and indicates that there is a bug somewhere, either in the accounting >>> or in the code in mm/page_alloc.c that tries to reserve some RAM for >>> __GFP_HIGH allocations. Can you have a look at that code? >>> >> The root cause is that CMA reserved 512M memory in 64K page size, and buddy allocator can not eat those memory. Some guys explain that ext4 filesystem don’t support migration page well, I didn’t dig into it yet. After unset CONFIG_CMA, the free memory can down to very low in 64K page size. Besides that, I found some weird problems in db410c. 1. there is no ZONE_NORMAL, only ZONE_DMA. I don’t know if there are bad influences, or bug in zone_sizes_init(). I have try to hard code max_dma to 64M in zone_sizes_init(), and it works. 2. 512M CMA memory in 64K page. Is the number normal? As I know, 4K page size only have 64M CMA memory. I have tracked the code, and found that the size passed to cma_declare_contiguous() function is the same as 4K page, but after call ALIGN(), the size increase to 512M. 3. As the test data indicated, CMA memory in 4K page can be consumed, but in 64K page, the result is not the same. A bug here? Pingbo

10 years, 8 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

10 years, 8 months

[RFC][PATCH] hikey: Add pstore platform driver for HiKey board

by John Stultz

Adds a platform driver to support pstore on HiKey (copied from the in-kernel ChromeOS driver). Also adds reservation in the hikey DTS and enables the feature in hikey_defconfig. Note: Unfortunately the ramoops DT driver never made it upstream, so I'm adding this via a platform driver. Would appreciate thoughts on how to best handle this. Cc: Rob Herring <rob.herring(a)linaro.org> Cc: Arnd Bergmann <arnd.bergmann(a)linaro.org> Cc: Haojian Zhuang <haojian.zhuang(a)linaro.org> Cc: Guodong Xu <guodong.xu(a)linaro.org> Cc: Vishal Bhoj <vishal.bhoj(a)linaro.org> Signed-off-by: John Stultz <john.stultz(a)linaro.org> --- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++ arch/arm64/configs/hikey_defconfig | 9 +++++ drivers/platform/Kconfig | 2 ++ drivers/platform/Makefile | 1 + drivers/platform/hikey/Kconfig | 27 +++++++++++++++ drivers/platform/hikey/Makefile | 2 ++ drivers/platform/hikey/hikey_pstore.c | 47 ++++++++++++++++++++++++++ 7 files changed, 93 insertions(+) create mode 100644 drivers/platform/hikey/Kconfig create mode 100644 drivers/platform/hikey/Makefile create mode 100644 drivers/platform/hikey/hikey_pstore.c diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts index f0cd5fa..a94f955 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts @@ -61,6 +61,11 @@ no-map; reg = <0x0 0x06dff000 0x0 0x00001000>; /* Mailbox message buf */ }; + + pstore@0x21f00000 { + no-map; + reg = <0x0 0x21f00000 0x0 0x00100000>; /* pstore/ramoops buffer */ + }; }; reboot_reason: reboot-reason@05f01000 { diff --git a/arch/arm64/configs/hikey_defconfig b/arch/arm64/configs/hikey_defconfig index e3cd02d..5313620 100644 --- a/arch/arm64/configs/hikey_defconfig +++ b/arch/arm64/configs/hikey_defconfig @@ -345,6 +345,8 @@ CONFIG_ANDROID_LOW_MEMORY_KILLER=y CONFIG_SYNC=y CONFIG_ION=y CONFIG_ION_HISI=y +CONFIG_HIKEY_PLATFORM=y +CONFIG_HIKEY_PSTORE=y CONFIG_MAILBOX=y CONFIG_HISI_MBOX=y CONFIG_HI6220_MBOX=y @@ -354,6 +356,7 @@ CONFIG_ANDROID=y CONFIG_ANDROID_BINDER_IPC=y CONFIG_REBOOT_REASON_SRAM=y CONFIG_EFI_VARS=y +CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_SECURITY=y CONFIG_BTRFS_FS=y @@ -371,6 +374,10 @@ CONFIG_TMPFS=y CONFIG_HUGETLBFS=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_XZ=y +CONFIG_PSTORE=y +CONFIG_PSTORE_CONSOLE=y +CONFIG_PSTORE_PMSG=y +CONFIG_PSTORE_RAM=y CONFIG_NFS_FS=y # CONFIG_NFS_V2 is not set CONFIG_NFS_V3_ACL=y @@ -385,6 +392,8 @@ CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOCKUP_DETECTOR=y +CONFIG_PANIC_ON_OOPS=y +CONFIG_PANIC_TIMEOUT=10 # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 5bd93a2..881c62b 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -7,3 +7,5 @@ endif source "drivers/platform/goldfish/Kconfig" source "drivers/platform/chrome/Kconfig" + +source "drivers/platform/hikey/Kconfig" diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index ca26925..b0e7286 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_MIPS) += mips/ obj-$(CONFIG_OLPC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ +obj-$(CONFIG_HIKEY_PLATFORM) += hikey/ diff --git a/drivers/platform/hikey/Kconfig b/drivers/platform/hikey/Kconfig new file mode 100644 index 0000000..5b36bba --- /dev/null +++ b/drivers/platform/hikey/Kconfig @@ -0,0 +1,27 @@ +# +# Platform support for Chrome OS hardware (Chromebooks and Chromeboxes) +# + +menuconfig HIKEY_PLATFORM + bool "Platform support for HiKey hardware" + depends on ARM64 + ---help--- + Say Y here to get to see options for platform support for + the HiKey board. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if HIKEY_PLATFORM + +config HIKEY_PSTORE + tristate "HiKey pstore support" + depends on ARM64 + ---help--- + This module instantiates the persistent storage on Hikey + devices. It can be used to store away console logs and crash + information across reboots. + + If you have a HiKey board, choose Y or M here. + The module will be called hikey_pstore. + +endif # HIKEY_PLATFORM diff --git a/drivers/platform/hikey/Makefile b/drivers/platform/hikey/Makefile new file mode 100644 index 0000000..7ab9173 --- /dev/null +++ b/drivers/platform/hikey/Makefile @@ -0,0 +1,2 @@ + +obj-$(CONFIG_HIKEY_PSTORE) += hikey_pstore.o diff --git a/drivers/platform/hikey/hikey_pstore.c b/drivers/platform/hikey/hikey_pstore.c new file mode 100644 index 0000000..1ab218b --- /dev/null +++ b/drivers/platform/hikey/hikey_pstore.c @@ -0,0 +1,47 @@ +/* + * hikey.c - Driver to instantiate HiKey ramoops device + * (Copied from ChromeOS ramoops implementation) + * + * Copyright (C) 2013 Google, Inc. + * Copyright (C) 2016 Linaro Limited + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, version 2 of the License. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/pstore_ram.h> + +static struct ramoops_platform_data hikey_ramoops_data = { + .mem_size = 0x00100000, + .mem_address = 0x21f00000, + .record_size = 0x20000, + .console_size = 0x20000, + .ftrace_size = 0x20000, + .dump_oops = 1, +}; + +static struct platform_device hikey_ramoops = { + .name = "ramoops", + .dev = { + .platform_data = &hikey_ramoops_data, + }, +}; + +static int __init hikey_pstore_init(void) +{ + return platform_device_register(&hikey_ramoops); +} + +static void __exit hikey_pstore_exit(void) +{ + platform_device_unregister(&hikey_ramoops); +} + +module_init(hikey_pstore_init); +module_exit(hikey_pstore_exit); + +MODULE_DESCRIPTION("HiKey pstore module"); +MODULE_LICENSE("GPL"); -- 1.9.1

10 years, 8 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

10 years, 8 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

10 years, 8 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,

10 years, 8 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

10 years, 8 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

10 years, 8 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

10 years, 8 months

← Newer
1
...
9
10
11
12
13
14
15
...
25
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev