Dev

dev@lists.96boards.org

197 discussions

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, 4 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, 5 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, 5 months

[ANN] Linaro Linux/Debian 15.11 release for DragonBoard 410c is available

by Nicolas Dechesne

hello there, A new release Linux release for the DragonBoard 410c is now available. The Linaro Linux release 15.11 is a Debian-based Linaro Build that provides developers with a desktop like environment using Ubuntu and the LXDE desktop, as well as a console-only image. What’s new in this release? * Based on Linux kernel v4.2.4 * Migration from Ubuntu 15.04 to Debian 8.0 (Jessie) * Various bug fixes and improvements reported on Bugzilla (including USB performance issue) Obviously, the main change is the migration to Debian, from Ubuntu, as I had announced in the previous release message. We believe it should be transparent for most users, if you need any assistance, or face any issues, please report on the forum or here. For more details and the list of bug fixes, or to download the release, please go to: http://builds.96boards.org/releases/dragonboard410c/linaro/debian/15.11 For general question or support request, please go to 96boards Community forum: 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=Dragonboard%20410c Finally, to get in touch with us, you can also use IRC: #96boards on irc.freenode.net On behalf of the Linaro Qualcomm Landing team, cheers, Nicolas

8 years, 5 months

JTAG @ Dragonboard

by Mateusz Kulikowski

Hi All, Contrary to popular believes, JTAG on Dragonboard seems to be operational. There is one catch - you need dongle worth thousands of USD for now :( I decided to write this post so maybe someone will help me to get it working on something cheaper. Short summary of my research below. @Peter - perhaps you could take a look and give some hints? 1) You need to solder JTAG connector to test points like that: http://rlyeh.eu/d/dragonboard_jtag.jpg (I suggest to protect test points as they're rather fragile and small). There is JTAG connector on the bottom, but I'm against using it because: - There are 4 DNI resistors (i.e. not installed) that have to be short. I don't know their location. - It requires fancy connector that is hard to get, and then you need some converter to standard 20-pin jtag cable. At least you need to solder: TDI, TDO, TMS, TCK, GND, VREF (VREG_L5_1P8) and TRST. I also wired SRST_N to RST pin of standard JTAG connector (but it's probably not needed) WARNING: you need dongle that is able to work/adapt to 1.8V. 2) There are 3 chips on JTAG chain, with software it's possible to disable some or all of them. Commands for OpenOCD: jtag newtap apq dap -expected-id 0x5ba00477 -irlen 4 <- This is ARM jtag newtap auto1 un1 -expected-id 0x000016dd -irlen 5 <- This is something (crypto processor?) jtag newtap auto2 un2 -expected-id 0x007060e1 -irlen 11 <- This is Hexagon core Commands for Trace32: Sum of length of all IR registers : 20. Number of JTAG devices (BYPASS registers) : 3. IDCODE of device 1 is : 0x007060e1 (QUALCOMM, QUALCOMM) SYS.CONFIG.DRPOST 0. SYS.CONFIG.DRPRE 2. SYS.CONFIG.IRPOST 0. SYS.CONFIG.IRPRE 9. (IRWIDTH 11.) IDCODE of device 2 is : 0x000016dd (Certicom Corporation, <unknown name>) SYS.CONFIG.DRPOST 1. SYS.CONFIG.DRPRE 1. SYS.CONFIG.IRPOST 11. SYS.CONFIG.IRPRE 4. (IRWIDTH 5.) IDCODE of device 3 is : 0x5ba00477 (ARM Ltd., ARM JTAG-DP DAP) SYS.CONFIG.DRPOST 2. SYS.CONFIG.DRPRE 0. SYS.CONFIG.IRPOST 16. SYS.CONFIG.IRPRE 0. (IRWIDTH 4.) <- This is ARM 3) Device configuration - single core for now: Commands for OpenOCD (they don't work though): target create apq aarch64 -chain-position apq.dap -dbgbase 0x80050000 -ctibase 0x80058000 -coreid 0 Commands for Trace32: SYStem.CPU CORTEXA53 SYStem.CONFIG CORENUMBER 1. SYStem.CONFIG.COREDEBUG.Base 0x80050000 SYStem.CONFIG.BMC.Base 0x80051000 SYStem.CONFIG.CTI.Base 0x80058000 SYStem.CONFIG.ETM.Base 0x8005c000 sys.option enreset off ;<-I'm not sure if this is needed for anything else than probe SYStem.Mode Attach 4) Results: - With Trace32, it is possible to attach, stop CPU. It's even possible to halt it in Secure mode (at least it looks like that). Some parts of memory (and system registers) are not accessible - probably ones that are Secure. - With OpenOCD (branch made by Peter Griffin), JTAG chain is visible properly, but probing of CPU fails: -------------- LOG Debug: 271 328 openocd.c:150 handle_init_command(): Examining targets... Debug: 272 328 target.c:1417 target_call_event_callbacks(): target event 21 (examine-start) Debug: 273 328 arm_adi_v5.c:647 ahbap_debugport_init(): Debug: 274 329 arm_adi_v5.c:688 ahbap_debugport_init(): DAP: wait CDBGPWRUPACK Debug: 275 329 arm_adi_v5.h:391 dap_dp_poll_register(): DAP: poll 4, mask 0x0820000000, value 0x20000000 Debug: 276 329 arm_adi_v5.c:695 ahbap_debugport_init(): DAP: wait CSYSPWRUPACK Debug: 277 329 arm_adi_v5.h:391 dap_dp_poll_register(): DAP: poll 4, mask 0x0880000000, value 0x80000000 Debug: 278 433 arm_adi_v5.h:404 dap_dp_poll_register(): DAP: poll 4 timeout Debug: 279 433 openocd.c:152 handle_init_command(): target examination failed -------------- END of LOG I've also attached diag data from Trace that can be useful for someone (I think I missed few DAP entries, but all CPUs are probably there). Best Regards, Mateusz

8 years, 5 months

enable Estuary Release Distribution on Hikey

by Xinwei Kong

hi all, HiKey will support Ubuntu, Debian and Fedora systerm and so on for estuary. visit:http://open-estuary.com/ You try Estuary for HiKey and if you meet testing problem, we will improve it. First, here is what you did: >>>> mkdir ~/work/open-estuary cd ~/work/open-estuary repo init -u https://github.com/open-estuary/estuary.git repo sync cd estuary ./build.sh -p HiKey -d Ubuntu >>>> Thank you xinwei

8 years, 5 months

← Newer
1
...
5
6
7
8
9
10
11
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev