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 all,
HiKey will support Ubuntu, Debian and Fedora systerm and so on for estuary.
visit:http://open-estuary.com/
You try Estuary for HiKey and if you meet testing problem, we will
improve it.
First, here is what you did:
>>>>
mkdir ~/work/open-estuary
cd ~/work/open-estuary
repo init -u https://github.com/open-estuary/estuary.git
repo sync
cd estuary
./build.sh -p HiKey -d Ubuntu
>>>>
Thank you
xinwei
Glad to share this news in list.
HiKey got supported by Estuary - Server Software stack, Open Sourced from
Huawei. Well, a more sophisticate explanation is here " Estuary is a
complete open source solution for ARM based systems for ICT domain. It can
provide you a quick launch pad to start with ARM Server Solution. "
http://open-estuary.com/estuary/
Every piece of it is committed to be open source. ATF/UEFI and kernel
support are coming from Linaro 96boards. Congrats team!
You can run Ubuntu, OpenSuse and some server software on top of HiKey.
Kernel in this build is v4.1.
Enjoy.
-Guodong
---------- Forwarded message ----------
From: Justin[Junhua] Zhao <zhaojunhua(a)hisilicon.com>
Date: 24 November 2015 at 19:47
Subject: !!!Important Notification: Estuary v2.1-rc0 released
To:
Hi, All,
The Estuary v2.1-rc0 is released now, anyone can get and use it freely,
any issue about it can be raised into Estuary Bug Tracker system as follows.
Release information: http://open-estuary.com/estuary-v2-1-rc0/
Documentations: http://www.open-estuary.com
Source code: https://github.com/open-estuary/estuary
Bug Tracker: http://open-estuary.com/issue-tracker/
Download guide: http://open-estuary.com/estuary-download/
For the website browser: Chrome 45.0.2454.85, IE 11, Firefox 40.0.3 are
recommended.
Changed log:
Change list for Estuary V2.1-rc0:
1. Update build.sh script
a. Support to build from project config file. e.g.:
./estuary/build.sh -f estuary/estuarycfg.json
b. Enable more boards(HiKey).
c. Enable application integration solution.
d. Dynamically install modules\firmwares into rootfs.
2. Upgrade UEFI
a. Resolved CPLD updating failed issue.
b. Enabled PCIE 3.0 auto link setup.
c. Enable HiKey board.
d. Resolved memory reducing issues when booting from provision.
3. Upgrade kernel
a. Enable HiKey board.
b. Resolved random MAC address issue.
4. Firstly integrate and enable some applications.(Currently only for
Ubuntu distribution)
Notes: it will take 2--4 hours for first times reboot, depending on
your network status.
a. Armor tools, e.g.: perf, strace ...
b. Docker v1.6.2
5. Improved some documents
6. Integrate HiBench and SysBench OLTP into Caliper.
7. Improved website
a. Optimized bug trucker system, implement closed-loop tracking
system.
b. Provided our own ftp server, and added special binaries download
page.
c. Fixed some issues about account register on website.
d. Added some guide about how to integrate new boards\applications
int Estuary.
--
==================================================
Best Regards,
赵俊化(Justin Zhao)
华为海思图灵软件架构组
Huawei Hisilicon Turing Software Architecture Team
Hi,
Some people here might be interested in this Inforce board:
http://inforcecomputing.com/blog/introducing-the-affordable-inforce-6309-mi…
It hits a similar price point (120$, but variants said to start at 99).
It has same physical dimensions, even down to the mounting holes.
Connector arrangement is different though.
LinuxGizmos reports that the software for it is:
"[…]based on Linaro’s upstream version."
http://linuxgizmos.com/tiny-rugged-sbc-runs-linux-or-android-on-snapdragon-…
I guess that means that db410c images will run on this one too with
little to no effort. As this is built around a QC SoC it of course
requires binary only bootloaders though.
Cheers
Thomas
PS: Now that compliance is fully optional and it has the same physical
dimensions, maybe it should be considered a 96borad too and be put on
the official webpage? SCNR
Hi All,
For those of you that are not tracking IRC/forums:
I've ported U-Boot to dragonboard.
For now it has to be chain-loaded from fastboot (you can flash it
to "boot" partition or boot with fastboot).
Basic things are already supported:
- USB host controller
- eMMC/SD (a bit slow)
- Some gpio's/leds
- Serial port
- Booting Linux
It can be helpful for people working on kernel, or just
for people that prefer u-boot to fastboot.
You can get it from my github repo:
https://github.com/hallor/u-boot
Most recent stable code is located on 'dragonboard' branch,
there also tags created once I release something important.
As there are currently no issues I'm aware of - I'm working on
cleaning-up the code for mainline, but if someone finds a bug or
missing (important) functionality - please let me know.
Best Regards,
Mateusz
Interesting things are happening, but many people on this list might not
be subscribed to linaro-announce, so here's a full quote:
On Sat, 7 Nov 2015 03:53:43 -0300, wrote:
> It took a bit longer than originally planned, but we're finally able
> to announce the first Reference Software Platform release (alpha).
>
> The Reference Software Platform Lead Project is part of the Linaro
> 96Boards initiative. The goal of the project is to deliver Linaro
> output for ARM SoCs using 96Boards products for use cases ranging from
> the Embedded to the Enterprise segments. This release includes
> bootloader, kernel, distributions (Debian) and AOSP. It comprise
> loadable software for the current 96Boards products (HiKey and
> Dragonboard410c), reference source code, and documentation on
> installing the images and building the source code.
>
> In case you are unfamiliar with the project, we had a great session
> that was presented during Linaro Connect SFO15, and it can be found at
> http://connect.linaro.org/resource/sfo15/sfo15-104-the-96boards-software-re…
>
> Goals we had for this release:
> * Bootstrap the CI jobs required to build and publish the components
> and images (more details at
> https://github.com/96boards/documentation/wiki/Reference-Software-CI)
> * Single Debian root file system that could be consumed by both HiKey
> and Dragonboard410c
> * Recent kernel, even if not yet fully functional, since the goal is
> to reduce maintenance and support overhead and accelerate ongoing
> development by focusing on upstream feature support
> * AOSP based on latest Android Release (6.0 Marshmallow), initially just HiKey
>
> A lot was accomplished during last month, and we're happy to announce
> that we're using a 4.3 based kernel for both HiKey and Dragonboard410c
> (Debian). The builds are still not sharing the same branch (due
> conflicts at the adv7511 driver), but we hope to be able to get this
> fixed over the next few weeks (and published as part of our next
> release).
>
> While the release supports many of the available hardware features for
> both Hikey and Dragonboard410c, it is in ALPHA state, so bugs are
> expected. For a better user experience, please use the previous
> releases available at
> https://builds.96boards.org/releases/dragonboard410c/ and
> https://builds.96boards.org/releases/hikey/.
>
> Highlights for this release:
>
> CE Debian RPBs:
> - Debian 8.2 "Jessie"
> - 4.3 kernel (with additional patches)
> - OpenJDK 8 included by default
> - 96Boards artworks and default settings
>
> CE AOSP RPB:
> - AOSP Android Marshmallow 6.0
> - 3.18 based kernel
>
> Install instructions, known issues, test reports and instructions to
> build from source are all published at
> https://github.com/96boards/documentation/wiki/ReferenceSoftware. We
> should also see more progress into a more complete set of
> documentation during the course of the next release.
>
> For general questions or support requests, please go to the
> 96boards.org Community forum - https://www.96boards.org/forums/.
> Please submit bugs to the 96Boards.org bugzilla
> (https://bugs.96boards.org/). For IRC support, please go to the
> #96boards channel @Freeode.
What about this mailing list?
> Make sure to check
> https://github.com/96boards/documentation/wiki/ReferenceSoftware for
> more information about this project and the release.
>
> Challenges for the next release (15.12 - official date to be announced):
> - Have both boards using a single kernel tree/branch and a single kernel binary
> - Better understanding about the upstream gaps
> - Adding support for CE AOSP for Dragonboard410c (with freedreno)
> - Adding support for CE OE/Yocto
> - Enterprise Edition
Here's a major challenge Linaro doesn't bother to acknowledge beyond
awkward IRC comments:
- Address the non-compliance of your 96boards
- Publish a compliant open source boot loader for db410c that loads
after ROM code, as required by spec. (see previous mails)
> We hope you enjoy the release!
I'm certainly going to try it out, it looks promising.
> On behalf of the Linaro 96Boards team,
>
> Ricardo Salveti
Cheers,
Thomas
PS: Please resist the obvious management approach "Let's adjust the spec
to match what we have". It would essentially completely discredit your
efforts and send the signal that Linaro does not care about those goals,
but instead completely bends to member commercial interests and those
boards are worthless for most use cases.
Acknowledge you fsckd up big time, publish a post mortem, consolidate
your compliance documentation to be less confusing, make sure all future
boards are compliant.
Hello Maxim,
I hit the situation well described in
https://gcc.gnu.org/ml/gcc-help/2015-02/msg00029.html , and wonder if
there's any updates to your answer since February?
I'm playing with Ubuntu 15.04, on Dragonboard (15.09 Linaro release).
Grepping thru output of apt-cache search, I found
gcc-4.9-multilib-arm-linux-gnueabi, installed it, which pulled armel
and armhf toochains, but didn't change linking behavior of "gcc
-mabi=ilp32". Trying to use a arm-linux-gnueabi-gcc-4.9 crosscompiler,
it builds executable, but it errors out with "./a.out: No such file or
directory" (missing dynamic linker?).
Btw, I had a suspicion that current gcc on that Ubuntu version (gcc
(Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2), when used with -mapi=ilp32,
defines uint64_t to be 4 bytes, and indeed it's true:
#include <stdint.h>
int main() {
printf("sizeof(uint64_t)=%d\n", sizeof(uint64_t));
}
gcc -mabi=ilp32 -S uint64.c
...
add w0, w0, :lo12:.LC0
mov w1, 4
bl printf
...
Thanks,
Paul
P.S. Any chance we could hope for -m32 switch, familiar from x86_64?
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I've heard that the next release will include SPI support, so this
might be already a bit old topic.
I'm trying SPI on HiKey according to the thread
https://www.96boards.org/forums/topic/hikey-board-spi/
with a .dsti hunk
spi_0: spi@f7106000 {
compatible = "arm,pl022", "arm,primecell";
reg = <0x0 0xf7106000 0x0 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
interrupts = <0 50 4>;
reset-controller-reg = <0x330 0x334 0x338 9>;
clocks = <&clock_sys HI6220_SPI_CLK>;
clock-names = "apb_pclk";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pmx_func &spi0_cfg_func>;
status = "ok";
};
on linux-xenomai kernel. Now it looks OK at least for the loop test
on the spidev which is added as a sub-node
spidev@0 {
compatible = "linux,spidev";
spi-max-frequency = <500000>;
reg = <0>;
};
and I can test sensors via spidev.
BTW, I've found that a few pl022 dt entries for other SoCs describe
two clocks and the first clock looks to be the one for SSPCLK.
I'm curious about how SSPCLK of amba pl022 is handled on HiKey.
Regards,
kaz
