[Arm-netbook] EOMA68-IC1t successful board bring-up

[Luke Kenneth Casson Leighton]

http://rhombus-tech.net/icubecorp/IC1T/news/

congratulations to the team at http://ICubeCorp.com for a successful
board bring-up, especially given the challenge that it had to be done
over the Micro-SD slot of the MicroDesktop base unit rather than over
USB-OTG. despite this they successfully got console access over UART
and have since sent the boards on to me for further testing.

i am really excited to be involved with a completely new processor,
and to be able to bring working prototypes to people.

l.

[Boris Barbour]

Post by Luke Kenneth Casson Leighton
http://rhombus-tech.net/icubecorp/IC1T/news/
i am really excited to be involved with a completely new processor,
and to be able to bring working prototypes to people.

Exciting news. Congratulations!

So this will be the box running TAILS...

[Alexander Stephen Thomas Ross]

great news! :D a non-evil soc, woohoo!
+1 boris, good point, a market for this board is the security, uprising,
activist,etc market. Wouldn’t it be ideal as a bitcoin wallet? or for
that sort of thing do you want extra special security features?



nice to see a pic of the micro desktop. nice and fairly compact. with a
pixel-qi 10inch lcd + touch panel you have a extra efficient tablet.
get a pixel-qi 10inch panel + driver here:
https://www.adafruit.com/products/1303

I'd use the vga in on the driver board.

[Boris Barbour]

Post by Alexander Stephen Thomas Ross
https://www.adafruit.com/products/1303

+1 Steven. I've been dreaming of a tablet liek that for ages. Big enough to
read technical pdfs (scientific papers) with fantastic battery life because of
ARM and pixel qi screen.

But, a tablet is harder to make, so it can't really come first. And, are the
larger pixel qi screens touch sensitive?

[Luke Kenneth Casson Leighton]

Post by Boris Barbour

Post by Luke Kenneth Casson Leighton
http://rhombus-tech.net/icubecorp/IC1T/news/
i am really excited to be involved with a completely new processor,
and to be able to bring working prototypes to people.

Exciting news. Congratulations!
So this will be the box running TAILS...

ok, bear in mind that this is an entirely new processor, with an
instruction set that has to use a port of the http://open64.net
compiler and the answer is "yes if you are prepared to compile it from
source".

for an entire OS like TAILS that's a very interesting question to answer :)

they have at least done the linux kernel, boot manager (i presume
it's u-boot), and android, so it's not like completely starting from
scratch.

l.

[Boris Barbour]

Post by Luke Kenneth Casson Leighton
bear in mind that this is an entirely new processor, with an
instruction set that has to use a port of the http://open64.net
compiler and the answer is "yes if you are prepared to compile it from
source".
for an entire OS like TAILS that's a very interesting question to answer :)

Ah. Oh well, at least there are no proprietary obstacles preventing progress.

[Luke Kenneth Casson Leighton]

Post by Boris Barbour

Post by Luke Kenneth Casson Leighton
bear in mind that this is an entirely new processor, with an
instruction set that has to use a port of the http://open64.net
compiler and the answer is "yes if you are prepared to compile it from
source".
for an entire OS like TAILS that's a very interesting question to answer :)

Ah. Oh well, at least there are no proprietary obstacles preventing progress.

*lol* no. i'm making some enquiries on how to do a debian port.

l.

[Philip Hands]

Post by Luke Kenneth Casson Leighton

Post by Boris Barbour

Post by Luke Kenneth Casson Leighton
bear in mind that this is an entirely new processor, with an
instruction set that has to use a port of the http://open64.net
compiler and the answer is "yes if you are prepared to compile it from
source".
for an entire OS like TAILS that's a very interesting question to answer :)

Ah. Oh well, at least there are no proprietary obstacles preventing progress.

*lol* no. i'm making some enquiries on how to do a debian port.

Look here: https://wiki.debian.org/DebianBootstrap

Cheers, Phil.
--
|)| Philip Hands [[phone]] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.phcomp.co.uk/pipermail/arm-netbook/attachments/20141014/ad3e5f62/attachment.sig>

[Wookey]

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
*lol* no. i'm making some enquiries on how to do a debian port.

Look here: https://wiki.debian.org/DebianBootstrap

As I just come to the end of the 2-4 year (depending what you count)
arm64 port, I can confirm that there is some expertise on this list on
how to do new debian ports.

#debian-bootstrap is the IRC channel to use for questions

Wookey

[Luke Kenneth Casson Leighton]

Post by Wookey

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
*lol* no. i'm making some enquiries on how to do a debian port.

Look here: https://wiki.debian.org/DebianBootstrap

As I just come to the end of the 2-4 year (depending what you count)
arm64 port, I can confirm that there is some expertise on this list on
how to do new debian ports.
#debian-bootstrap is the IRC channel to use for questions

awesome. daunting, but awesome :)

l.

[Manuel A. Fernandez Montecelo]

Post by Wookey

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
*lol* no. i'm making some enquiries on how to do a debian port.

Look here: https://wiki.debian.org/DebianBootstrap

As I just come to the end of the 2-4 year (depending what you count)
arm64 port, I can confirm that there is some expertise on this list on
how to do new debian ports.
#debian-bootstrap is the IRC channel to use for questions

I am helping with OpenRISC or1k in particular, but also helped a bit
modifying packages which benefited all of the Debian ports added lately
(arm64, ppc64el, mips64el and or1k). I can probably lend a hand in an
effort to get a Debian port of this new architecture, but of course
people like Wookey have much more experience than me.

A difficult part that I see is if GCC cannot generate code for this
architecture. I think that many packages expect to be compiled in GCC,
and if they are libraries or important pieces of infrastructure, they
will block packages depending on them. Even if it's a tiny percentage,
there are more than 10K source packages in Debian nowadays, so it's not
a minor task.


risc-v/lowrisc could also be an interesting project, both for EOMA-68
and and a Debian port, if the project succeds in producing usable
silicon products next year.


Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>

[Luke Kenneth Casson Leighton]

On Thu, Oct 16, 2014 at 6:37 PM, Manuel A. Fernandez Montecelo

Post by Manuel A. Fernandez Montecelo

Post by Wookey

Post by Philip Hands

Post by Luke Kenneth Casson Leighton
*lol* no. i'm making some enquiries on how to do a debian port.

Look here: https://wiki.debian.org/DebianBootstrap

As I just come to the end of the 2-4 year (depending what you count)
arm64 port, I can confirm that there is some expertise on this list on
how to do new debian ports.
#debian-bootstrap is the IRC channel to use for questions

I am helping with OpenRISC or1k in particular, but also helped a bit
modifying packages which benefited all of the Debian ports added lately
(arm64, ppc64el, mips64el and or1k). I can probably lend a hand in an
effort to get a Debian port of this new architecture, but of course
people like Wookey have much more experience than me.
A difficult part that I see is if GCC cannot generate code for this
architecture. I think that many packages expect to be compiled in GCC,
and if they are libraries or important pieces of infrastructure, they
will block packages depending on them. Even if it's a tiny percentage,
there are more than 10K source packages in Debian nowadays, so it's not
a minor task.

there's always a way round that: a package that "pretends" it is gcc
(i think it is something like "Provides")

Post by Manuel A. Fernandez Montecelo
risc-v/lowrisc could also be an interesting project,

yeees... my only reservation is that they have a golden opportunity
to create something that's actually commercially desirable.... and
they are probably instead going to create something that is only of
interest to academia.

l.

[Manuel A. Fernandez Montecelo]

Post by Luke Kenneth Casson Leighton
On Thu, Oct 16, 2014 at 6:37 PM, Manuel A. Fernandez Montecelo

Post by Manuel A. Fernandez Montecelo
A difficult part that I see is if GCC cannot generate code for this
architecture. I think that many packages expect to be compiled in GCC,
and if they are libraries or important pieces of infrastructure, they
will block packages depending on them. Even if it's a tiny percentage,
there are more than 10K source packages in Debian nowadays, so it's not
a minor task.

there's always a way round that: a package that "pretends" it is gcc
(i think it is something like "Provides")

Yes, there are several ways to achieve that... but I meant that maybe some
projects will only compile with GCC (or run properly if compiled with GCC),
because they assume quirks in implementation, invalid syntax in language
standards but valid in GCC, and things like that. Like the reasons why Linux
kernel does not compile with LLVM. I think that many projects might have
similar problems if the compiler is not GCC.

E.g., even after years of efforts getting the archive compiled with Clang:

"22202 packages have been rebuild. Among them, 1261 (5.7 %) failed."

http://clang.debian.net/

I suspect that the numbers if using open64 compiler will be much worse.

--
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>

[Luke Kenneth Casson Leighton]

On Thu, Oct 16, 2014 at 11:14 PM, Manuel A. Fernandez Montecelo

Post by Manuel A. Fernandez Montecelo

Post by Luke Kenneth Casson Leighton
On Thu, Oct 16, 2014 at 6:37 PM, Manuel A. Fernandez Montecelo

Post by Manuel A. Fernandez Montecelo
A difficult part that I see is if GCC cannot generate code for this
architecture. I think that many packages expect to be compiled in GCC,
and if they are libraries or important pieces of infrastructure, they
will block packages depending on them. Even if it's a tiny percentage,
there are more than 10K source packages in Debian nowadays, so it's not
a minor task.

there's always a way round that: a package that "pretends" it is gcc
(i think it is something like "Provides")

Yes, there are several ways to achieve that... but I meant that maybe some
projects will only compile with GCC (or run properly if compiled with GCC),
because they assume quirks in implementation, invalid syntax in language
standards but valid in GCC, and things like that. Like the reasons why Linux
kernel does not compile with LLVM. I think that many projects might have
similar problems if the compiler is not GCC.

well, we just have to suck it and see. i think we will get a lot of
support from ICubeCorp (hopefully this will not overwhelm their
engineers) as they will *definitely* want to know when something
doesn't work... and fix it!

bear in mind that this team have taken an amazingly brave step of
creating an entirely new architecture from scratch: they want to make
sure it succeeds, and is properly tested and reliable. so reports to
them "compiler broke" are something they will pay attention to!

that's one case. the other - when bits of software break or don't
compile - that's ... *sigh* gonna be fun. we'll just have to go
through them all one-by-one.

i'm not a huge fan of maintaining patches by-hand. i've used bitbake
before, to great effect. its ability to store (and apply) patches at
*different phases* of a build... in a *reproducible and automated*
fashion is ... absolutely invaluable.

there are even some patterns where configure is called, folliowed by
the autom4te cache being monkey-patched (or even replaced!) where
cross-compiling (particularly from 64-bit host of 32-bit targets) is
known (and guaranteed) to fail due to screw-ups by the developers or
just because it's simply not possible to do the right thing *ever*.

bitbake's recipies comprise over fifteen years of highly-diverse
cross-compiling of tens of thousands of packages across _hundreds_ of
disparate systems from embedded with only 8mb of FLASH right the way
up to full desktop GNU/Linux distros that can be put onto standard x86
64-bit PCs.

i think it would be a wise idea to hack that expertise into
submission and codify a DebianPorts system into it as a set of (mostly
new) recipes.

l.

[Paul Sokolovsky]

Hello,

On Thu, 16 Oct 2014 23:56:53 +0100
Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

[]

Post by Luke Kenneth Casson Leighton

Post by Manuel A. Fernandez Montecelo
Yes, there are several ways to achieve that... but I meant that
maybe some projects will only compile with GCC (or run properly if
compiled with GCC), because they assume quirks in implementation,
invalid syntax in language standards but valid in GCC, and things
like that. Like the reasons why Linux
kernel does not compile with LLVM. I think that many projects
might have similar problems if the compiler is not GCC.

well, we just have to suck it and see. i think we will get a lot of
support from ICubeCorp (hopefully this will not overwhelm their
engineers) as they will *definitely* want to know when something
doesn't work... and fix it!

Sorry, if you said that Cray, Inc. engineers would work on that
(because rumors say its their architecture, though I didn't see
someone presenting datasheet comparisons) - that at least somehow
would sound plausible, but ICubeCorp engineers? Ughh.

Do you follow ESP8266 WiFi chip teh-drama? The piece is supposed to
send bankrupt all western IoT chip makers (or maybe not), because
Chinese guys did something which guys like TI can't get right for years
with their CC3000 stuff.

The story unfolds as follows: The guys behind ESP8266
(https://espressif.com/) figured that while they have something cute
(heck, it even has builtin balun), the big guys like Mediatek and
Qualcomm are on their ass with their (much crappier) solutions. So,
they did 2 things: dumped ESP8266 on the markets on unbelievably low
price and leaked SDK based on proprietary compiler (which in turn is
based on Open64, what a coincidence!)

But of course they understand that they can't beat Mediatek and
Qualcomm with illegal leaked proprietary SDK, only legal open source
can be the answer. So they said they work on making GCC SDK.

And here's the salt of the story - no, they can't make it. Because in 2
weeks after ESP8266 went viral, the community, with the help of Cadence
engineers (Cadence now owning the Xtensa arch on which ESP8266's CPU is
based) already had a working GCC compiler:
https://github.com/jcmvbkbc/gcc-xtensa . So, the only choice Espressif
engineers are left with is to slowpoke for couple more months, then
take community work, screw it up a bit so it was professionally looking
proprietary stuff and release as theirs.


So, I wouldn't bet much on how far "ICubeCorp" could go without real
community involvement with their CPUs.

[Luke Kenneth Casson Leighton]

Post by Paul Sokolovsky
Hello,
On Thu, 16 Oct 2014 23:56:53 +0100
[]

Post by Luke Kenneth Casson Leighton

Post by Manuel A. Fernandez Montecelo
Yes, there are several ways to achieve that... but I meant that
maybe some projects will only compile with GCC (or run properly if
compiled with GCC), because they assume quirks in implementation,
invalid syntax in language standards but valid in GCC, and things
like that. Like the reasons why Linux
kernel does not compile with LLVM. I think that many projects
might have similar problems if the compiler is not GCC.

well, we just have to suck it and see. i think we will get a lot of
support from ICubeCorp (hopefully this will not overwhelm their
engineers) as they will *definitely* want to know when something
doesn't work... and fix it!

Sorry, if you said that Cray, Inc. engineers would work on that
(because rumors say its their architecture, though I didn't see
someone presenting datasheet comparisons) - that at least somehow
would sound plausible, but ICubeCorp engineers? Ughh.

well, actually i since did some more checking and the news i saw
basically says it's a from-scratch design.

Post by Paul Sokolovsky
And here's the salt of the story - no, they can't make it. Because in 2
weeks after ESP8266 went viral, the community, with the help of Cadence
engineers (Cadence now owning the Xtensa arch on which ESP8266's CPU is
https://github.com/jcmvbkbc/gcc-xtensa .

ooo i _like_ the xtensa architecture, i spoke with them a while back.
did you know that the majority of audio codec ICs world-wide use the
xtensa dsp core? a few years ago before they were bought they claimed
to have *1.6 billion* licenses world-wide.

cool huh? :)