Hi,
Does the HiKey board have a unique ID in the SoC that can be
read out and that allows identifying different boards in
software (e.g. in UBoot, Linux...)?
Anything that is quasi-fixed in the hardware would be nice,
e.g. a serial number in ROM or fuses that can be read
directly. A unique root key in a peripheral that can be used
to generate something would also work. Where does the MAC of
board's ethernet port comes from actually?
Axel
"I'm here to kick a** and chew bubblegum … and I'm all out of
bubblegum!" or maybe not?
A new 96 CE board appears on the official pages:
http://www.96boards.org/products/ce/bubblegum96/
This one's been making various appearances for at least half a year now,
so one could expect well matured hardware and software building on
lessons learned from the first two boards.
Note that listing on the page implies passed compliance:
" Linaro will review the self-certification results for a submitted
96Boards product. At its sole discretion Linaro may request board
samples for further testing. Once a compliance report has been approved
the vendor may use the 96Boards branding and logo according to published
terms and conditions, and the vendor product will be added to the
96Boards website(s)."
Any chance to have a look at that compliance report?
So, where are the Schematics, the mandatory documentation, the SoC TRM, etc?
Will there be at least one open source bootloader provided for the board
that executes immediately after the internal SoC startup code?
…
(Hint, nothing yet so far on the official 96borad webpage)
I'd like to chew some bubblegum, but will it kick a**?
Cheers
Thomas
Hi, all
Here is a summary and status report about HiKey in vanilla linux and our
upstreaming plan.
As of v4.4, already upstreamed:
- clk, psci, basic dts, uart, cpufreq, cpuidle, mailbox, emmc, wifi driver
fix, and tsensor (thermal)
- hikey can boot using vanilla v4.4 kernel and defconfig.
Based on v4.4, topic branches are available, and integration branch is
hosted here:
- Git repo: https://github.com/96boards-hikey/linux
- Integration branch: hikey-mainline-rebase
<https://github.com/96boards-hikey/linux/tree/hikey-mainline-rebase>
- Topics (so features) include: dts, pmic, mmc, usb, adv7511, drm, pm, gpu,
bluetooth, ion, hisi-reset, hikey-configs. (Most of *these are backport of
what we sent in maillist for community review.*)
- pre-builds are available too, if you just want to download and give it a
try:
https://builds.96boards.org/snapshots/hikey/community/hikey-mainline-rebase/
Moving onward,
v4.5-rc1:
USB: driver, 37dd9d6 usb: dwc2: add support of hi6220.
Slated for v4.6 merge-window:
hisi-reset driver: in linux-next (
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/driver…
)
DTS: in maintainer's git repo: <https://github.com/hisilicon/linux-hisi>
- Including: gpio, pinctrl, i2c
More work targeting v4.6:
DTS: need submit to hit v4.6: usb, mmc, wifi, and led.
pmic, regulator: sent v6 on 18/Jan. In maillist review.
- http://thread.gmane.org/gmane.linux.kernel/2129489
drm: v2 on 28/Nov. In maillist review. v3 will be sent in early Feb.
- http://www.spinics.net/lists/dri-devel/msg95283.html
adv7533: common driver with qualcomm dragonboard, investigations ongoing to
have a single driver
Work in progress that might miss 4.6:
mmc: by early Feb., to send v1 of patch to mailing list.
-
clk: hi6220: register reset clocks for mmc: (will drop. Need re-write to
use hisi-reset framework which exists in linux-next.)
-
mmc: dw_mmc: hikey: add this support for high speed sd card (will
refactor and send maillist).
Idle and mailbox: Reserve memory regions and enabling idle states: Resend
V2 after alignment with DT maintainers:
Mailbox V3 sent out for review and discussed at Connect
[2015/Oct].
- [2016/1/29] two steps:
1) add dts for reserving memory regions and enabling idle states; because
MCU is quite depend on memory regions, otherwise it will introduce unstable
issue for mailbox driver as well. This step targets v4.6.
2) add mailbox driver.
coresight: [2016/1/29] in v4.4, etm0 is ok. etm1~7 can cause system hang -
still under investigation.
smmu: V2 [2015/Oct.]:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/449391
- Actually we want to combine ION and smmu together. Now ION code is not
ready yet.
bluetooth: TI's driver is not fully upstreamed. Need to enable with
additional patches. (Enabled on v4.4 kernel.)
HDMI audio: in-progress. v3.18 was added. v4.4 not added yet.
- Basic function is ok, but there is noise. Need to rewrite the DMA driver.
Hi all,
I've spent some time over the past couple of days getting update-grub
working on the hikey. It works for me, but I need some review. The
solution consists of three parts:
1) a new config file in /etc/default/kernel that can contain
KERNEL_DEVICETREE="<board-name>"
2) a new script in /etc/kernel/postinst.d/devicetree that copies the
requested device tree file into /boot when KERNEL_DEVICETREE is set
3) a modifcation to /etc/grub.d/10_linux that will add the devicetree
command when KERNEL_DEVICETREE is set.
I've also be partially successful using the grub-install tool. It will
install the grubaa64.efi application correctly in
(ESP)/EFI/debian/grubaa64.efi, but barfs when trying to update the EFI
variables which is unsurprising. However, the system boots fine when I
copy the installed grubaa64.efi into (ESP)/EFI/BOOT/grubaa64.efi
With these changes I can install a kernel package, and grub gets
updated correctly with the new kernel information.
Hello everyone,
About 3 months have silently passed, without anything visibly changing.
I can't help but ask myself if Linaro has abandoned the 96borad effort
in its original form and resolved to make it a mostly Linaro internal
project. Don't get me wrong, I wouldn't mind, even in such a form it
would ultimately benefit the broader audience in terms of better
upstream support of ARMv7 and AArch64.
I do think though, that "the community" deserves to know if they are
still part of the target audience and can count on any form of support.
Personally I have a bit of a "Pandaboard past OMAPgeddon" feeling at the
moment
Thomas
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
