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/
>
>
>
Hi,
If you haven't noticed yet, the RaspberryPi 3 was unveiled today. It
sports a quad cortex A53 arrangement:
http://hackaday.com/2016/02/28/introducing-the-raspberry-pi-3
I guess that settles where the community will flock for 64bit ARM.
Hobbyists and Makers can now get a small and affordable SBC, that at the
same time is compliant with THE gold standard for community boards: RPi.
Cheers
Thomas
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
