Hi,
When verified some patches on linux-next branch I found Debian rootfs
cannot be mounted successfully on Hikey, the booting log is:
http://termbin.com/akar
>From the log, we can see:
mount: mounting udev on /dev failed: Device or resource busy
...
ALERT! /dev/disk/by-partlabel/system does not exist. Dropping to a
shell!
So I bisected the linux-next branch and narrow down below patch which
introduces mounting failure; after applied this patch, the kernel will
mount devtmpfs on '/dev', then later udev cannot mount again for
devfs. Finally cannot find '/dev/disk/by-partlabel/system' for rootfs.
I don't know what's the best way to fix this issue, welcome any
suggestion for this. And report this issue in case it may impact later
Debian release?
Thanks,
Leo Yan
---8<---
>From ee35011fd0324b37fbb046561e58d4d6bae798ac Mon Sep 17 00:00:00 2001
From: Rob Landley <rob(a)landley.net>
Date: Fri, 19 May 2017 07:39:23 +1000
Subject: [PATCH] initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT
Make initramfs honor CONFIG_DEVTMPFS_MOUNT, fixing 2b2af54a5bb6 ("Driver
Core: devtmpfs - kernel-maintained tmpfs-based /dev"), which didn't
bother. Move /dev/console open after devtmpfs mount, and update help
text.
Commit 456eeabab849 in 2005 made gen_initramfs_list (when run with no
arguments) spit out an 'example' config creating /dev and /dev/console.
The kernel accidentally(?) included this for many years when you didn't
specify initramfs contents, and of course grew dependencies on this
/dev/console node in the (often hidden) initramfs. c33df4eaaf41 ("disable
init/initramfs.c") in 2007 explicitly preserved this dependency.
2bd3a997befc ("init: Open /dev/console from rootfs") in 2010 claimed it
"removes the occasionally problematic assumption that /dev/console exists
from the boot code" but actually just moved it later.
But nobody never tested statically linking an initramfs. If you point
CONFIG_INITRAMFS_SOURCE at a directory running the build as a normal user
you _don't_ get a /dev/console (because you can't create it without being
root, and can't use the existing one out of /dev unless you create your
own initramfs list file), in which case init runs with stdin/stdout/stderr
closed and you get no output.
Eric's test case for his 2010 commit referenced above was:
With this patch I was able to throw busybox on my /boot partition
(which has no /dev directory) and boot into userspace without
problems.
But it didn't work pointing CONFIG_INITRAMFS_SOURCE at a directory of the
same files. This provides the "automatically mounting devtmpfs on /dev"
workaround the earlier commit was trying to avoid.
Link: http://lkml.kernel.org/r/21935caf-501d-e97c-5611-5c4af7e0f9ae@landley.net
Signed-off-by: Rob Landley <rob(a)landley.net>
Cc: Eric W. Biederman <ebiederm(a)xmission.com>
Cc: Jean-Paul Saman <jean-paul.saman(a)nxp.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Cc: Yang Shi <yang.shi(a)linaro.org>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: Emese Revfy <re.emese(a)gmail.com>
Cc: Petr Mladek <pmladek(a)suse.com>
Cc: Fabian Frederick <fabf(a)skynet.be>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/base/Kconfig | 14 ++++----------
init/main.c | 15 +++++++++------
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d718ae4..74779ee 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -48,16 +48,10 @@ config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
depends on DEVTMPFS
help
- This will instruct the kernel to automatically mount the
- devtmpfs filesystem at /dev, directly after the kernel has
- mounted the root filesystem. The behavior can be overridden
- with the commandline parameter: devtmpfs.mount=0|1.
- This option does not affect initramfs based booting, here
- the devtmpfs filesystem always needs to be mounted manually
- after the rootfs is mounted.
- With this option enabled, it allows to bring up a system in
- rescue mode with init=/bin/sh, even when the /dev directory
- on the rootfs is completely empty.
+ Automatically mount devtmpfs at /dev on the root filesystem, which
+ lets the system to come up in rescue mode with [rd]init=/bin/sh.
+ Override with devtmpfs.mount=0 on the commandline. Initramfs can
+ create a /dev dir as needed, other rootfs needs the mount point.
config STANDALONE
bool "Select only drivers that don't need compile-time external firmware"
diff --git a/init/main.c b/init/main.c
index f866510..9ec09ff 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1038,12 +1038,6 @@ static noinline void __init kernel_init_freeable(void)
do_basic_setup();
- /* Open the /dev/console on the rootfs, this should never fail */
- if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
- pr_err("Warning: unable to open an initial console.\n");
-
- (void) sys_dup(0);
- (void) sys_dup(0);
/*
* check if there is an early userspace init. If yes, let it do all
* the work
@@ -1055,8 +1049,17 @@ static noinline void __init kernel_init_freeable(void)
if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
ramdisk_execute_command = NULL;
prepare_namespace();
+ } else if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT)) {
+ sys_mkdir("/dev", 0755);
+ devtmpfs_mount("/dev");
}
+ /* Open the /dev/console on the rootfs, this should never fail */
+ if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
+ pr_err("Warning: unable to open an initial console.\n");
+ (void) sys_dup(0);
+ (void) sys_dup(0);
+
/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
--
2.7.4
Hi,
I am trying to set up a simple demo for a lightning talk at FOSSAsia
later this week and I was able to get the blinking LED examples set up
quite easily thanks to the OpenHours video. I am however unable to
get the beacon example working.
I am using the master branch from the zephyr project and on reset the
device throws the following on UART:
Starting Beacon Demo
[bt] [ERR] bt_enable: No HCI driver registered
Bluetooth init failed (err -19)
indicating that bluetooth is not enabled. I'll probably spend some
time looking at the code later today/tomorrow (even though I don't
actually know what I'm looking for right now :)) but I figured I put
this out here in case I may have missed out on something elementary.
I tried a couple of branches on the Linaro github repo as well (master
and carbon to be precise) but neither worked. The carbon branch in
fact refused to build, but that's an unrelated problem.
Thanks,
Siddhesh
Hi all,
for one of my projects I need my Android device to act as a Bluetooth LE
peripheral device. I noticed this feature has been added in Android 5.0
(https://developer.android.com/about/versions/android-5.0.html).
Unfortunately my Nexus 4 is unlikely to get this feature
(https://altbeacon.github.io/android-beacon-library/beacon-transmitter-devic…).
But I also have a 96Board Hikey board that has become an official
platform in AOSP.
Is there a plan to support Bluetooth LE peripheral role to Hikey? If
yes, any idea of the ETA?
I would not necessary excited to do it but if there is no plan I would
add the support myself. I am familiar with GATT (Bluez), JNI, Linux
Kernel, Android application. I know the Hikey is capable of BLE
peripheral as I already used Bluez and its DBus interface to make Hikey
appears a BLE peripheral.
I am new to AOSP world. So I am a bit lost in the various components. I
already read these pages:
- https://source.android.com/devices/index.html: Android Interfaces and
Architecture
- https://source.android.com/devices/bluetooth.html: Bluetooth
- https://source.android.com/devices/Android-6.0-Bluetooth-HCI-Reqs.pdf:
Android 6.0 Bluetooth HCI Requirements
I understand the HAL peripheral support is generally divided in module
(defined by hw_module_t) and device (defined by hw_device_t).
I saw HAL interfaces are defined by libhardware and potentially the one
that would interest me is `bt_gatt_server.h`.
But I am a bit unclear by the link between Android Bluetooth HCI and
`bt_gatt_server.h`.
If I wanted to add GATT Server to Hikey what should I do?
Sorry if you have nothing to do with this issue. I collected emails
around repositories and web resources. I am not sure who is the best
person to answer this question.
Thanks in advance,
Olivier
Hi Guys,
I am looking to setup dual boot with Android (emmc) and Ubuntu (SD) on
hikey board. And am facing some difficulties currently.
I took bootloaders from here:
http://builds.96boards.org/snapshots/hikey/linaro/uefi-openplatformpkg/57/
Debian SD card image from:
http://builds.96boards.org/snapshots/reference-platform/debian/latest/hikey/
and did dd to the SD card which has boot and rootfs
partitions now.
I took AOSP images from here:
http://builds.96boards.org/releases/hikey/linaro/aosp/latest/
and I am using boot_fat.uefi.img.
Now when the SD card isn't inserted and pin 5-6 are shorted, the board
boots into fastboot with options to boot from SD, emmc, etc. I can boot
into emmc and boot android just fine. All works fine. If I insert the SD
card now, I can see the partitions in /dev/block/mmcblk1**.
But, if I insert the SD card before booting up, then I get this on terminal:
http://pastebin.com/A7JkPZS7 and don't see any more prints after that.
If I power on the board before inserting SD card and get up to the menu,
where I can select SD or emmc or fastboot and then insert SD card, the
minicom terminal hangs.
I have tried two 8 GB SDHC cards from Trascend and sandisk already.
Any clues ?
--
viresh
Hi all,
Sorry for spamming, I want to check if someone has finished the kdump
enabling work on 96boards? Particularly I'm interesting in enabling
on DB410c or Hikey boards.
The flow is as below:
First kernel booting
`-> Wartchdog reset
`-> second kernel booting
`-> Dump DDR by USB port or into SD card
Due kdump enabling involves many components and need take care the
memory regions allocation for ARM-TF, UEFI, kernels; so if you have
made some progress for this, please let me know and this could save
much time to avoid duplicate works.
Thanks,
Leo Yan
Silently a new 96board starts appearing: Cello
It seems to be produced by LeMaker and is based around the AMD A1100
SoC. That's the same as on the illusive Husky, actually both boards look
very similar with only minor differences in the placement of some
connectors.
The LeMaker product page has it up for preorder for 299$; with an
estimated shipping time frame of 2016Q2.
http://www.lenovator.com/product/103.html
This could mean the first "cheap" 64 bit ARM server board becoming
available. Also more power: A57 cores.
Though I'm sure hrw will still disapprove as it has SATA, but is a weird
non-industry-standard form factor.
Oh, and the obligatory question:
Will it be 96boards compliant and are we going to get to see the actual
compliance report?
Cheers
Thomas
Hi all,
I'm working one MediaTek X20 96boards, and install one Mezzanine
board on it so can try to see if UART can work well or not.
After tried to switch Mezzanine's Jumpers in J1 to UART0, so
I can see it can print out some logs; but later images print out log
but totally cannot be unrecognized, please see below log info.
Tried to change baudrate from 115200 to 38400, but it's no lucky. So
the unrecognized char issue is not caused by baudrate. Before I
look into detailed kernel configuration, I'd like check if any guy has
fixed this issue, could you point out what's wrong for this?
Thanks in advance.
Leo Yan
---8<---
F0: 102B 0000
F3: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0041 [0000]
G0: 0190 0000
EC: 0000 0000 [0001]
T0: 0000 0163 [000F]
Jump to BL
READY*3 Sw ?2"0
Rr?9?
*
?r
smNBrpt*sB:t*?_@
??M
2 Er
)#"?JBb*
rJ:0
?&?
r
?( &b*??
?J/1r:]
*' )
"B: ?pZ
6J
R8r*B?K*
#
I'm pleased to announce the 16.06 release for the Reference Software
Platform project!
This is the fourth release, and like its predecessors, it has seen
quite a few changes and improvements for both Consumer and Enterprise
platforms.
The Reference Software Platform has seen many substantial changes,
among other more subtle ones.
Below is a list of some of this release’s highlights:
Common to both Consumer and Enterprise Editions
==============================================
* Kernel
- Unified tree shared between the CE and EE builds
- 4.4.11-based, including some under-review topic branches to extend
the features and platform hardware support
- Device-Tree support for CE; ARM ACPI and PCIe support for Enterprise
- Added OP-TEE support (enabled on HiKey and Juno)
- Supports Reference HW platforms HiKey and Cello (Other Test
Platforms include: Dragonboard 410c, Hisilicon D02 and D03,
APM X-Gene, HP Proliant m400, AMD Overdrive, Qualcomm Q2432:ZB,
and Cavium ThunderX)
- Single kernel config for all platforms in
arch/arm64/configs/distro.config
- Single kernel binary (package) for all platforms
* Bootloader
- UEFI OpenPlatformPkg (upstream) now contains reference implementations
for Huawei D02/D03, AMD Overdrive and LeMaker Cello
- U-boot support in Dragonboard 410c images to allow easier handling of
images
Consumer Edition
================
* Reference hardware platform
- LeMaker Hikey
* Other supported test platforms
- Dragonboard 410c
* Overall CE Debian platform features, validated as part of the release
- UEFI with DT
- Upgrade to Debian 8.5 “Jessie”
- Upgrade to the unified 4.4.11 Linux Kernel
- Upgrade graphics components: Mesa 11.1.2 and XServer 1.17.3a
- Rootfs automatically resized during the first boot
* CE Debian RPB for HiKey:
- OP-TEE integrated by default
- UEFI updated to use the latest development trees based on Tianocore
and OpenPlatformPkg
* CE Debian build for DragonBoard 410c:
- U-boot chain-loaded from LK
* CE OE/Yocto RPB:
- First OpenEmbedded-based RPB, including several changes and
components merged from the LHG OE layers
- Dragonboard 410c and HiKey support
- HiKey features: OP-TEE and Mali support
- Dragonboard 410c features: GPU, WLAN, BT, audio, LS I/O, camera and
GPS support
Enterprise Edition
==================
* Reference hardware platform
- LeMaker Cello
* Other supported test platforms
- AMD Overdrive A0 and B0
- Hisilicon D02
- Hisilicon D03 (new)
- APM X-Gene Mustang
- HP ProLiant m400
- Qualcomm Q2432LZB (new)
- Cavium ThunderX (new)
* Overall platform features, validated as part of the release
- UEFI with ACPI
- KVM
- PCIe
* Firmware
- UEFI OpenPlatformPkg (upstream) now contains reference implementation
for Huawei D02/D03, AMD Overdrive and LeMaker Cello
* Network Installers
- Use the unified 4.4.11 kernel
- Debian upgrade to Debian 8.5 “Jessie”
- CentOS upgrade to CentOS 7.2 16.03
* Enterprise Components
- Docker 1.9.1
- OpenStack Liberty for Debian Jessie and CentOS
- ODPi 1.0.0 based Hadoop
- Spark 1.3.1
- OpenJDK 8
- QEMU 2.6
Known issues with this release
==============================
Install instructions, known issues, test reports and instructions to
build from source are all published on:
https://github.com/96boards/documentation/wiki/Reference-Platform-Home
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
(e.g. AMD Overdrive and HiSilicon D02/D03), please use:
https://bugs.linaro.org
On behalf of the Reference Platform teams,
--
Fathi Boudra
Engineering Manager | Builds and Baselines, Release
Linaro.org | Open source software for ARM SoCs
Hi Baoquan,
I also add support(a)linaro.org so we can track and follow up your
questions more formally. Also translate your question into English as
we can ask more English speaker to help for related questions as needed.
So the questions is "how to profiling IPA and enable ftrace event for
it"?
- In generally, please don't manually do this thing by yourself.
Workload-automation has prepared all this profiling flow already:
https://github.com/ARM-software/workload-automation
This docuemenation is very important when you want to easily start:
https://github.com/ARM-software/workload-automation/blob/master/doc/source/…
- To enable workload-automation, you need set configuration file at
host PC side so it can connect with board smoothly:
This file usually is in the folder:
~/.workload_automation/config.py; so "wa" command will use this
configuration file to connect target board.
- Then need define the testing configuration file so that can run the
test case automatically, enabling ftrace events, and finally
output profiling log files, you can refer the file:
ipa_tunning.yaml;
wa run ~/ipa_tunning.yaml -d ipa_tunning
So finally you will all logs are saved in "ipa_tunning" folder.
- After get the result, it will save trace.dat file into the log
folder, so you can use trappy to analyse the file for temperature
curves. The trappy have a very good example file is:
https://github.com/ARM-software/trappy/blob/master/doc/00%20-%20Quick%20sta…
I have enclosed my ~/.workload_automation/config.py file and
ipa_tunning.yaml for reference. If have any further question, just let
me know.
Thanks,
Leo Yan
On Mon, Jun 20, 2016 at 05:05:03PM +0800, lu.baoquan(a)zte.com.cn wrote:
> Hi,All,
>
> 我们目前在Android6+Kernel4.1上面测试IPA。
>
> 目前情况是：
> 1.使能IPA；
> 2.打开Function Tracer，下面这些events是否满足
> trace-cmd record -e cpu_frequency* -e cpu_idle -e thermal -e
> thermal_power_allocator
>
> WA和TRAPpy对我们来说都是全新的，能否提供一个ready的模板：
> 能否提供一个WA Agenda的模板
> 能否提供TRAPpy相关分析脚本，如果能和WA结合出一个结果。然后我们可以做其他修
> 改。
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately.
