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
Hi, Nico and Fathi
https://github.com/96boards/96boards-tools/commit/7d2d6c5d4f3f4a1488fe75024…
Bruce from Lemaker reported this issue when he tries to use
'resize-helper.sh' to resize his SD card on HiKey. Here is his log.
Would you please have a check? Does his procedure correct?
-Guodong
On 27 January 2016 at 10:19, bruce.zou <bruce.zou(a)lemaker.com> wrote:
> Hi，
>
>
>
> 昨天聊的这个问题，帮忙看看哈。重启后没有任何变化。
>
>
>
> root@linaro-alip:~# lsblk
>
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
>
> mmcblk0boot0 179:64 0 4M 1 disk
>
> mmcblk0boot1 179:128 0 4M 1 disk
>
> mmcblk0 179:0 0 7.3G 0 disk
>
> ├─mmcblk0p1 179:1 0 1M 0 part
>
> ├─mmcblk0p2 179:2 0 1M 0 part
>
> ├─mmcblk0p3 179:3 0 1M 0 part
>
> ├─mmcblk0p4 179:4 0 8M 0 part
>
> ├─mmcblk0p5 179:5 0 2M 0 part
>
> ├─mmcblk0p6 179:6 0 64M 0 part /boot/efi
>
> ├─mmcblk0p7 179:7 0 256M 0 part
>
> ├─mmcblk0p8 179:8 0 256M 0 part /media/linaro/cache
>
> └─mmcblk0p9 179:9 0 6.7G 0 part
>
> mmcblk1 179:192 0 7.4G 0 disk
>
> ├─mmcblk1p1 179:193 0 68M 0 part /media/linaro/boot
>
> └─mmcblk1p2 179:194 0 2G 0 part /
>
> root@linaro-alip:~# ./resize-helper.sh
>
> Warning: The kernel is still using the old partition table.
>
> The new table will be used at the next reboot.
>
> The operation has completed successfully.
>
> Error: Partition doesn't exist.
>
> resize2fs 1.42.12 (29-Aug-2014)
>
> The filesystem is already 506880 (4k) blocks long. Nothing to do!
>
> root@linaro-alip:~#
>
>
>
>
>
> *Bruce Zou*
>
>
> *Making Innovation EasyLeMaker Team -- The Professional Makers for
> Hardware and Software Customization.*
>
> Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China
> Post Code: 518055
>
> Email:
> support(a)lemaker.org (Technical Support)
> product(a)lemaker.org (Product Distribution)
>
> http://www.lemaker.org/
>
>
>
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
V2: Fix compile error for error commit
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..279063c 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
The Arduino toolchain needs some help to know which UART to use when
running on a 96Board. This file adds two environmental variables to
configure both the IDE and command line Arduino tools.
JAVA_TOOL_OPTIONS adds the correct UART to the GUI IDE
MONITOR_PORT sets the correct UART for the Arduino.mk Makefile tools
Signed-off-by: Grant Likely <grant.likely(a)linaro.org>
---
This works on my platform, but it is only part of a patch. The debian
package needs to be updated to install this file as a configuration
file.
Slightly off topic, I think that we need to move to this approach for
selecting the correct serial port and get rid of the /etc/udev/rules.d
rule. The udev rule approach is fragile, and a shell script can make
intelligent decisions about how the UART is mapped to the 96Boards LS
connector.
96boards-sensors.sh | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 96boards-sensors.sh
diff --git a/96boards-sensors.sh b/96boards-sensors.sh
new file mode 100644
index 000000000000..efb1c4a8c1e8
--- /dev/null
+++ b/96boards-sensors.sh
@@ -0,0 +1,5 @@
+# Environmental variables for working with the 96Boards Sensors adapter
+#
+# Copy this file into /etc/profile.d to set up the correct environment by default
+export JAVA_TOOL_OPTIONS="-Dgnu.io.rxtx.SerialPorts=/dev/tty96B0"
+export MONITOR_PORT=/dev/tty96B0
--
2.5.0
I just build vanilla v4.4 with arm64 defconfig and it doesn't boot on
hikey. What patch set and config do I need?
I need a minimal set of patches to add to an existing project.
-Geoff
The patch sets add support for Hi6220 PMIC Hi655x MFD core and its
regulator driver.
Current testing and support board is Hikey which is one of 96boards.
It is an arm64 open source board. For more information about this board,
please access https://www.96boards.org.
This is hardware layout for access PMIC Hi655x from AP SoC Hi6220.
Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
We can use memory-mapped I/O to communicate.
+----------------+ +-------------+
| | | |
| Hi6220 | SSI bus | Hi655x |
| |-------------| |
| |(REGMAP_MMIO)| |
+----------------+ +-------------+
V2: Code refactoring of regulator.
V3: Drop mtcmos from this patch and use regmap-irq.
V4: Move the vset-table to driver code and donot open code for it.
V6: Use regulators_node and of_match, donot open code fot it.
Chen Feng (5):
doc: bindings: Add document for mfd hi665x PMIC
doc: bindings: Document for hi655x regulator driver
mfd: hi655x: Add hi665x pmic driver
regulator: add regulator driver of hi655x pmic
hisilicon/dts: Add hi655x pmic dts node
.../devicetree/bindings/mfd/hisilicon,hi655x.txt | 28 +++
.../regulator/hisilicon,hi655x-regulator.txt | 28 +++
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 87 ++++++++
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 1 +
drivers/mfd/hi655x-pmic.c | 170 +++++++++++++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/hi655x-regulator.c | 227 +++++++++++++++++++++
include/linux/mfd/hi655x-pmic.h | 56 +++++
11 files changed, 621 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
create mode 100644 Documentation/devicetree/bindings/regulator/hisilicon,hi655x-regulator.txt
create mode 100644 drivers/mfd/hi655x-pmic.c
create mode 100644 drivers/regulator/hi655x-regulator.c
create mode 100644 include/linux/mfd/hi655x-pmic.h
--
1.9.1
Hi,
I'm trying to flash HiKey board using standard procedure but I'm not
getting any signs of life on the host laptop after connecting the USB
cable. I checked both recovery mode and fastboot.efi. I tested with 2
cables and different USB sockets on my laptop and USB hub. Has anyone
seen the failure like this? The board is flashed with alip image and
can boot just fine.
Cheers,
milosz
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
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..279063c 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
When a process fork a child process, we should not allow the
child process use the binder which opened by parent process.
But if the binder-object creater is a thread of one process who exit,
the other thread can also use this binder-object normally.
We can distinguish this by the member proc->tsk->mm.
If the thread exit the tsk->mm will be NULL.
proc->tsk->mm != current->tsk->mm && proc->tsk->mm
So only allow the shared mm_struct to use the same binder-object and
check the existence of mm_struct.
Signed-off-by: Chen Feng <puck.chen(a)hisilicon.com>
Signed-off-by: Wei Dong <weidong2(a)hisilicon.com>
Signed-off-by: Junmin Zhao <zhaojunmin(a)huawei.com>
Reviewed-by: Zhuangluan Su <suzhuangluan(a)hisilicon.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index a39e85f..3a74c5d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2736,6 +2736,8 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
+ if (unlikely(proc->tsk->mm != current->tsk->mm && proc->tsk->mm))
+ return -EINVAL;
trace_binder_ioctl(cmd, arg);
--
1.9.1
