Dev

dev@lists.96boards.org

197 discussions

by Geoff Levand

Hi, Just for anyone interested, I bought an FTDI Chip TTL-232RG-VREG1V8-WE (1.8 volt) USB to TTL serial cable and soldered the wire leads the the Hikey J16 as so: ftdi orange (TX) - Hikey pin2 (RX) ftdi yellow (RX) - Hikey pin4 (TX) ftdi black (GND) - Hikey pin3 (GND) ftdi red (VCC) - open ftdi green (RTS) - open ftdi brown (CTS) - open Seems to be working fine. [1] http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232RG_CA… -Geoff

10 years, 10 months

Intermittent hang in BL1

by Peter Griffin

Hi, Further to Jeromes email about hangs / compiler flags for BL1. I find on my hikey board with software which usually boot OK, around 1 in 5 cold boots I can provoke another hang in BL1. Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):9a97502 NOTICE: BL1: Built : 08:13:36, Mar 10 2015 0000000002000000000000000200000000000000020000000000000002000000 (repeating at 1Hz) Has anyone else experienced this? regards, Peter.

10 years, 10 months

Success using Bluetooth keyboard and playing audio using A2DP on the HiKey board...

by Scott Bambrough

I've been playing with Bluetooth and have had some success. I started with Debian snapshot 132. If flashed the boot partition with boot-fat.img and the system partition with hikey-jessie_developer_20150319-132.img. This gave me a Debian Jessie console image. The Debian Jessie image uses BlueZ 5.23 on the HiKey, and there are not a lot of instructions on the internet for using BlueZ5. BlueZ4 and BlueZ5 are quite different, many of the utilities in BlueZ4 no longer exist. Snapshot 132 allows you to power on the BT radio and discover devices. You can also pair the HiKey with most devices. However the kernel in snapshot 132 does not support BT HID devices. We need to alter the kernel configuration to build BT HID support as a module, and install it on the images (see the attached patch). I rebuilt the kernel, and the boot-fat.image with it and flashed. I also had to rebuild the system partition with modules to match my kernel and flash it into the system partition. Once I did that the following works: Setup Bluetooth Keyboard ------------------------------------------ $ sudo su # bluetoothctl -a [bluetooth]# power on [bluetooth]# agent KeyboardOnly [bluetooth]# default-agent [bluetooth]# pairable on [bluetooth]# scan on [bluetooth]# pair 01:02:03:04:05:06 [bluetooth]# trust 01:02:03:04:05:06 [bluetooth]# connect 01:02:03:04:05:06 [bluetooth]# quit After this I can type and see characters on the HDMI console. If the keyboard disconnects due to power off I had to run bluetoothctl and connect again. To fix this: Create file: /etc/bluetooth-keyboard.conf with the following contents # Config file for bluetooth-keyboard.service # Set BTKBDMAC to the Bluetooth address of your keyboard. # Using built in TI WiLink Bluetooth, device is hci0 BTKBDMAC = 00:1F:20:24:B2:EF HCIDEVICE = hci0 Create file: /etc/systemd/system/bluetooth-keyboard.service with the following contents [Unit] Description=Automatically connect to a Bluetooth keyboard Documentation=https://wiki.archlinux.org/index.php/Bluetooth_Keyboard Requires=dbus-org.bluez.service After=dbus-bluez.org.service ConditionPathExists=/etc/bluetooth-keyboard.conf ConditionPathExists=/usr/bin/hcitool ConditionPathExists=/usr/bin/hciconfig [Service] Type=oneshot EnvironmentFile=/etc/bluetooth-keyboard.conf ExecStart= ExecStart=/usr/bin/hciconfig ${HCIDEVICE} up # Ignore errors on connect, spurious problems seem to occur with Bluetooth? Start next command with - to ignore the errors. ExecStart=-/usr/bin/hcitool cc ${BTKBDMAC} After this I did the following: # systemctl daemon-reload # systemctl start pulseaudio.service Now the keyboard connects when disconnected and a key is pressed reliably. After a reboot, I can login on the HDMI console using the Bluetooth keyboard. References: https://wiki.archlinux.org/index.php/bluetooth_keyboard Setup Bluetooth Audio -------------------------------------------------- As I said before Debian Jessie uses BlueZ 5.23. Unfortunately BlueZ5 dropped support for ALSA. This means we have to use PulseAudio for Bluetooth audio support. Debian Jessie uses PulseAudio 5 on the HiKey. At present, PulseAudio 5 only supports the A2DP Bluetooth profile and not the HSP/HFP Bluetooth profiles (at least according to the reference). The latter profiles are apparently under development. To get Bluetooth audio working on my HiKey I did the following: $ sudo su # apt-get install --no-install-recommends pulseaudio pulseaudio-module-bluetooth Create file: /etc/systemd/system/pulseaudio.service with the following contents [Unit] Description=Pulse Audio [Service] Type=simple ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disable-shm [Install] WantedBy=multi-user.target Create file: /etc/dbus-1/system.d/pulseaudio-bluetooth.conf with the following contents <busconfig> <policy user="pulse"> <allow send_destination="org.bluez"/> </policy> </busconfig> Append to file: /etc/pulse/system.pa ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif Add user linaro to pulse-access group #id linaro uid=1000(linaro) gid=1000(linaro) groups=1000(linaro),4(adm),20(dialout),24(cdrom),29(audio),30(dip),44(video),46(plugdev),1001(admin) # usermod -a -G pulse-access # id linaro uid=1000(linaro) gid=1000(linaro) groups=1000(linaro),4(adm),20(dialout),24(cdrom),29(audio),30(dip),44(video),46(plugdev),1001(admin),115(pulse-access) Now need to start up PulseAudio # systemctl daemon-reload # systemctl start pulseaudio.service Now need to pair and connect to the Bluetooth speaker. Pairing only needs to be done once. # bluetoothctl [bluetooth]# agent on [bluetooth]# default-agent [bluetooth]# scan on [bluetooth]# pair A0:E9:DB:5C:FA:67 [bluetooth]# trust A0:E9:DB:5C:FA:67 [bluetooth]# connect A0:E9:DB:5C:FA:67 [bluetooth]# quit # exit Now connected to Bluetooth speaker, and user linaro should be able to use PulseAudio. Now list devices in PulseAudio. $ pactl list The output for me near the end looks like this. Card #0 Name: bluez_card.A0_E9_DB_5C_FA_67 Driver: module-bluez5-device.c Owner Module: 14 Properties: device.description = "Nude Super-M" device.string = "A0:E9:DB:5C:FA:67" device.api = "bluez" device.class = "sound" device.bus = "bluetooth" device.form_factor = "headset" bluez.path = "/org/bluez/hci0/dev_A0_E9_DB_5C_FA_67" bluez.class = "0x240404" bluez.alias = "Nude Super-M" device.icon_name = "audio-headset-bluetooth" device.intended_roles = "phone" Profiles: a2dp: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes) off: Off (sinks: 0, sources: 0, priority: 0, available: yes) Active Profile: a2dp Ports: headset-output: Headset (priority: 0, latency offset: 0 usec) Part of profile(s): a2dp headset-input: Headset (priority: 0, latency offset: 0 usec, not available) If the active profile isn't A2DP, then set it $ pactl set-card-profile 0 a2dp Should now be able to play a sound and hear it on speaker. $ paplay -d bluez_sink.A0_E9_DB_5C_FA_67 /usr/share/sounds/alsa/Front_Center.wav References: https://github.com/ev3dev/ev3dev/issues/198 -- Scott Bambrough Technical Director, Member Services Linaro

10 years, 10 months

Re: [Dev] HiKey: ARM TF BL1 hangs when compiled with GCC 4.9

by Maxim Kuvyrkov

> On Mar 19, 2015, at 9:24 PM, Tyler Baker <tyler.baker(a)linaro.org> wrote: > > FYI, not sure if you are on 96boards dev list Thanks Tyler! [I'm not on the mailing list, so will have to reply in a new thread.] > > ---------- Forwarded message ---------- > From: Jerome Forissier <jerome.forissier(a)linaro.org> > Date: 19 March 2015 at 11:18 > Subject: [Dev] HiKey: ARM TF BL1 hangs when compiled with GCC 4.9 > To: dev <dev(a)lists.96boards.org> > > > Hi all, > > I am running the ARM Trusted Firmware on my HiKey board. I found that BL1 hangs if I build it with the version of GCC that comes with my Ubuntu 14.10 distribution [1] or with another 4.9 build from Linaro [2]. However, it works as expected if I use the 4.8 Linaro build [3] as recommended on the HiKey UEFI wiki [4]. > > Basically I found two separate issues, and I'm not sure if they are bugs in GCC or HiKey ATF. Here is the story... > > With GCC 4.9 [1], the boot hangs, LED#2 blinks and "00000000f20003e8" is printed on UART0 about every second. Let's call this bug #1. The hang occurs in hi6220_pll_init() [5], execution never gets passed this line: > mmio_write_32(0x0, 0xa5a55a5a); > > So I checked the objdump outputs (bl1.dump). > > - Working compiler [3] gives: > f98041f0: d2800000 mov x0, #0x0 // #0 > f98041f4: 528b4b41 mov w1, #0x5a5a // #23130 > f98041f8: 72b4b4a1 movk w1, #0xa5a5, lsl #16 > f98041fc: b9000001 str w1, [x0] > > - Bad compiler [1] produces: > f9804184: d2800000 mov x0, #0x0 // #0 > f9804188: b900001f str wzr, [x0] > f980418c: d4207d00 brk #0x3e8 > > What?! Is there some kind of smart detection in the compiler assuming that one shouldn't write to address zero? Yes, this is exactly correct. Compiler assumes that it is compiling normal application user-level code, and treats references to null address as undefined code, which it is free to optimize as it sees fit. In this case the compiler seems to have decided that value in w1 register is never used because it is live only on the path that leads to write-to-null. Note, that the compiler still kept the write itself to keep parity in thrown exceptions between original and optimized code. Any code that references null address as a valid memory location should use -fno-delete-null-pointer-checks compiler flag. This flag is often added automatically for toolchains that target bare-metal, and, I'm guessing, you are using a "normal" aarch64-linux-gnu toolchain. > > If I change address to 0x4, the code goes past this location but later hangs with the same LED status as above (b0100) and code "0000000096000021" on the console. This is bug #2. > > I tracked it down to the initialization of some structures on the stack when entering usb_handle_control_request() [6]. Looks like an alignment issue, since removing the packed attribute on struct usb_endpoint_descriptor [7] fixes the bug. Let us (Linaro TCWG) know if this doesn't go away with -fno-delete-null-pointer-checks. The best way is to file a bug for GCC product in bugs.linaro.org. > > So... What kind of bugs do you guys think we have here, and who should I report them to? > > [1] aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.9.1-16ubuntu6) 4.9.1 > [2] aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 4.9.3 20141031 (prerelease) > [3] aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) 4.8.3 20140401 (prerelease) > [4] https://github.com/96boards/documentation/wiki/UEFI > [5] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445… > [6] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445… > [7] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445… > -- Maxim Kuvyrkov www.linaro.org

10 years, 10 months

HiKey - thermal

by Jorge Ramirez-Ortiz

Should we expect any thermal issues if we leave the Hikeys always on?

10 years, 10 months

Re: [Dev] HiKey U-Boot port

by Linus Walleij

On Tue, Mar 17, 2015 at 12:16 PM, Peter Griffin <peter.griffin(a)linaro.org> wrote: > For fun I've done a minimal U-Boot port for the HiKey board, I thought I'd > post it here in case anyone else is interested. This work is based on top of > Linus Walleij Juno port. Nice work, as mentioned I think all deps are upstream and you should be able to just rebase on master and start to submit patches upstream. It seems the most useful part of my stuff was the ATF docs and my funky makefiles :) Yours, Linus Walleij

10 years, 10 months

dilemma - enable PSCI

by Fathi Boudra

Hi, There's a change pending to enable PSCI on HiKey: https://github.com/96boards/linux/pull/15 A regression is introduced when using HiSilicon bootloader: we'll have one core when using Hisilicon's bootloader. Here's the summary: * current dtb + hisilicon bootloader: boot images, all cores enabled * current dtb + uefi: boot images, one core enabled * psci enabled dtb + hisilicon bootloader: boot images, one core enabled * psci enabled dtb + uefi: boot images, all cores enabled It won't be much of an issue since the long term plan is to deprecate HiSilicon bootloader in favor of UEFI. Unfortunately, UEFI isn't feature complete (SD card support missing, flash to eMMC limited to 128M, etc...). In the meantime, moving forward it's proposed to provide a legacy dtb and use the PSCI enabled combination (UEFI + kernel) as the default as it is the long term plan. It mitigates the issue for people using HiSilicon bootloader while it enables people using UEFI. Another option is to keep the status quo until UEFI is there (speculation is "in 2 weeks") and switch the default dtb at that time. The question is which default dtb should be used? Opinions? Cheers, Fathi

10 years, 10 months

Issue with hikey USB OTG serial adapter

by Tyler Baker

Hi, I have been trying to flash Peter's u-boot port to my early access hikey board without success. I'm stuck trying to use the burn-boot tool as the usb-serial device used in download mode keeps disconnecting. [ 165.408788] option 3-3:1.0: device disconnected [ 251.495189] usb 3-3: new full-speed USB device number 6 using xhci_hcd [ 251.624288] usb 3-3: New USB device found, idVendor=12d1, idProduct=3609 [ 251.624292] usb 3-3: New USB device strings: Mfr=1, Product=4, SerialNumber=0 [ 251.624293] usb 3-3: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸 [ 251.624295] usb 3-3: Manufacturer: 䕇䕎䥎 [ 251.624780] option 3-3:1.0: GSM modem (1-port) converter detected [ 251.624862] usb 3-3: GSM modem (1-port) converter now attached to ttyUSB0 [ 252.131320] usb 3-3: USB disconnect, device number 6 [ 252.131539] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [ 252.131560] option 3-3:1.0: device disconnected What I have tried and has not worked. * Using various PC's, System76 laptop w/Ubuntu 14.10, Chromebook Pixel 2 w/Debian 8, and Dell XPS8700 w/Debian 8 headless. All these system show the kernel messages above. * Disabling network manager * sudo echo 12D1 3609 > /sys/bus/usb-serial/drivers/option1/new_id; sudo mknod /dev/ttyUSB0 c 188 0 as suggested by the wiki * Using other micro-usb cables. * Created a script to loop the burn-boot tool Any thing else to try? Thanks, -- Tyler Baker Tech Lead, LAVA Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

10 years, 10 months

[PATCH] hikey: hi6220: ensure output directory exists

by Tyler Baker

Fixes a build error, as the output directory may not exists. Signed-off-by: Tyler Baker <tyler.baker(a)linaro.org> --- hikey-u-boot.mak | 1 + 1 file changed, 1 insertion(+) diff --git a/hikey-u-boot.mak b/hikey-u-boot.mak index dda967e..12d5f51 100644 --- a/hikey-u-boot.mak +++ b/hikey-u-boot.mak @@ -16,6 +16,7 @@ have-crosscompiler: build: have-crosscompiler FORCE rm -rf $(build_dir) + @mkdir -p $(output_dir) @mkdir -p $(build_dir) $(MAKE) O=$(build_dir) CROSS_COMPILE=$(CROSS_COMPILE) distclean $(MAKE) O=$(build_dir) CROSS_COMPILE=$(CROSS_COMPILE) hikey_aemv8a_config -- 2.1.0

10 years, 10 months

[PATCH 1/2] mmc: dwmmc-k3: set disable boot for initialization

by Haojian Zhuang

If mmc controler is accessed in bootloader, it's required to execute disable boot before resetting the controller & enabling the clock in kernel driver. Signed-off-by: Haojian Zhuang <haojian.zhuang(a)linaro.org> --- .../devicetree/bindings/mmc/k3-dw-mshc.txt | 7 +++++ drivers/mmc/host/dw_mmc-k3.c | 33 ++++++++++++++++++++++ drivers/mmc/host/dw_mmc.h | 1 + 3 files changed, 41 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index 3b35449..cf12cfa 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -14,6 +14,13 @@ Required Properties: * compatible: should be one of the following. - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions. +Optional Properties: + +* "hisilicon,disable-boot" + - Disable boot before reseting mmc controller and enabling clocks. It's + required on Hisilicon Hi6220 SoC if the mmc controller is accessed in + bootloader. + Example: /* for Hi3620 */ diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c index 83a9f49..3042a7c 100644 --- a/drivers/mmc/host/dw_mmc-k3.c +++ b/drivers/mmc/host/dw_mmc-k3.c @@ -11,6 +11,7 @@ #include <linux/module.h> #include <linux/platform_device.h> #include <linux/clk.h> +#include <linux/delay.h> #include <linux/mmc/host.h> #include <linux/mmc/dw_mmc.h> #include <linux/of_address.h> @@ -29,8 +30,40 @@ static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios) host->bus_hz = clk_get_rate(host->ciu_clk); } +static void disable_boot(struct dw_mci *host) +{ + int timeout = 0; + unsigned int data; + + mci_writel(host, CTRL, SDMMC_CTRL_FIFO_RESET); + mci_writel(host, CMD, SDMMC_CMD_START | SDMMC_CMD_DISABLE_BOOT); + + while (1) { + data = mci_readl(host, CMD) & 0x80000000; + if (data == 0) + break; + if (timeout < 2000) { + timeout++; + mdelay(1); + } else { + dev_warn(host->dev, "failed to stop MMC\n"); + break; + } + } +} + +static int dw_mci_k3_parse_dt(struct dw_mci *host) +{ + struct device_node *np = host->dev->of_node; + if (of_find_property(np, "hisilicon,disable-boot", NULL)) { + disable_boot(host); + } + return 0; +} + static const struct dw_mci_drv_data k3_drv_data = { .set_ios = dw_mci_k3_set_ios, + .parse_dt = dw_mci_k3_parse_dt, }; static const struct of_device_id dw_mci_k3_match[] = { diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h index 01b99e8..8c5977b 100644 --- a/drivers/mmc/host/dw_mmc.h +++ b/drivers/mmc/host/dw_mmc.h @@ -115,6 +115,7 @@ #define SDMMC_CMD_START BIT(31) #define SDMMC_CMD_USE_HOLD_REG BIT(29) #define SDMMC_CMD_VOLT_SWITCH BIT(28) +#define SDMMC_CMD_DISABLE_BOOT BIT(26) #define SDMMC_CMD_CCS_EXP BIT(23) #define SDMMC_CMD_CEATA_RD BIT(22) #define SDMMC_CMD_UPD_CLK BIT(21) -- 1.9.1

10 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev