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.
On Tuesday 14 October 2014 15:41:37 Luke Kenneth Casson Leighton wrote:
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...
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.
On Tuesday 14 October 2014 17:04:48 Alexander Stephen Thomas Ross wrote:
get a pixel-qi 10inch panel + driver here: 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?
On Tue, Oct 14, 2014 at 3:42 PM, Boris Barbour boris.barbour@ens.fr wrote:
On Tuesday 14 October 2014 15:41:37 Luke Kenneth Casson Leighton wrote:
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.
On Tuesday 14 Oct 2014 17:10:09 Luke Kenneth Casson Leighton wrote:
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.
On Tue, Oct 14, 2014 at 8:31 PM, Boris Barbour boris.barbour@ens.fr wrote:
On Tuesday 14 Oct 2014 17:10:09 Luke Kenneth Casson Leighton wrote:
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.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
On Tue, Oct 14, 2014 at 8:31 PM, Boris Barbour boris.barbour@ens.fr wrote:
On Tuesday 14 Oct 2014 17:10:09 Luke Kenneth Casson Leighton wrote:
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 [2014-10-14 21:54 +0100]:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
*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
On Wed, Oct 15, 2014 at 12:27 AM, Wookey wookey@wookware.org wrote:
+++ Philip Hands [2014-10-14 21:54 +0100]:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
*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.
2014-10-15 00:27 Wookey:
+++ Philip Hands [2014-10-14 21:54 +0100]:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
*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@gmail.com
On Thu, Oct 16, 2014 at 6:37 PM, Manuel A. Fernandez Montecelo manuel.montezelo@gmail.com wrote:
2014-10-15 00:27 Wookey:
+++ Philip Hands [2014-10-14 21:54 +0100]:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
*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")
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.
2014-10-16 20:55 Luke Kenneth Casson Leighton:
On Thu, Oct 16, 2014 at 6:37 PM, 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."
I suspect that the numbers if using open64 compiler will be much worse.
-- Manuel A. Fernandez Montecelo manuel.montezelo@gmail.com
On Thu, Oct 16, 2014 at 11:14 PM, Manuel A. Fernandez Montecelo manuel.montezelo@gmail.com wrote:
2014-10-16 20:55 Luke Kenneth Casson Leighton:
On Thu, Oct 16, 2014 at 6:37 PM, 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.
Hello,
On Thu, 16 Oct 2014 23:56:53 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
[]
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.
On Fri, Oct 17, 2014 at 12:55 AM, Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
On Thu, 16 Oct 2014 23:56:53 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
[]
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.
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 .
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? :)
arm-netbook@lists.phcomp.co.uk
-
Alexander Stephen Thomas Ross -
Boris Barbour -
Luke Kenneth Casson Leighton -
Manuel A. Fernandez Montecelo -
Paul Sokolovsky -
Philip Hands -
Wookey