Arduino TRE

[jpnorair 340]

@@jpnorair Either way, x86 is not RISC, and some would argue that neither is an ARM Cortex A processor. Depends on which definition you go by I suppose. Quite honestly, I have not taken a close look at the Quark. I suppose I assumed it was x86 at least in a basic sense. Perhaps I assumed wrong. All I am concerned with from a personal standpoint is *if* it can run standard x86 software. If this is the case, then all the issues that come with other architectures should go away. *shrug*

x86 used to be a classic CISC ISA.  Then, starting in Pentium Pro IIRC (and definitely by Pentium 3), Intel implemented a RISC core with a hardware translator.

 

I don't think it is important for Quark to run "standard x86 software."  I'm not even sure what that is.  As long as Linux has thorough support for architecture X or Y or Z, then there is not really any compatibility problem.  20 years ago, it was a big deal to support one ISA or another.  Nowadays, it is about supporting one OS or another.

[yyrkoon 250]

I don't think it is important for Quark to run "standard x86 software."  I'm not even sure what that is.  As long as Linux has thorough support for architecture X or Y or Z, then there is not really any compatibility problem.  20 years ago, it was a big deal to support one ISA or another.  Nowadays, it is about supporting one OS or another.

Really ? 

 

Seriously, you should try and run software on ARM Linux, and note the differences between x86 Linux. You'll run into all sorts of issues outside of your package manager. Then perhaps even using package repo's from your distro.

 

For example I want to make a Linux appliance out of my Beagelbone. First thought is using Snorkel(embedded web server SDK - cross platform type). Snorkel does not "support" hardfloat ARM( eabihf ), and what it does "support" is still in beta( has been for a very long time ). Next thought was perhaps nodejs would work. Which in fact works great now. BUt it is not a simple task to get things working. You have to compile on the target. This is not far from normal. But you can not always use the latest sources. This is trial and error. Passed that if you use npm to install modules, you better watch it because there is a chance it'll install x86 binaries . . . No one says that every software "developer" has to be smart.

 

This is just one small example, of many potential "issues" that will arise while working with Linux on ARM.

 

EDIT

 

Anyway, the feeling I get now is as it was 10+ years ago using some Linux distro's. The OS almost seems to want to fight against you sometimes. Usually when it is something important, that you *have* to use. 

[veryalive 49]

--------------  a great thread, guys      !!!!!!!!!!!

[jpnorair 340]

Seriously, you should try and run software on ARM Linux, and note the differences between x86 Linux. You'll run into all sorts of issues outside of your package manager. Then perhaps even using package repo's from your distro.

"x86 linux" is not cut and dry.  There are many different families of x86, even for the desktop.  If you are running one of the types that is well-supported, then it's easy.  I'm sure you've noticed how many configuration and compiler flags go into it.  The same goes for ARM platforms, although there are more varieties.

 

The example you gave about lack of hard-float support is a good one, because the same kinds of differences will exist between Quark and desktop x86 as observed between various ARM devices.

[yyrkoon 250]

In this context the "i386" release of Debian is what I speak of specifically. It'll run on just about anything that *is* x86. Including the newer AMD and Intel 64 bit desktop classed processors. Italium would be a different story, and AMD has no similar processors that I am aware of. At least  I have not heard of a recent Opteron( but owning an older Opteron, I know it will run the same software as a desktop classed processors ).

 

Hell, an Opteron will work just fine on a desktop classed motherboard. Or at least this used to be the case.

[jpnorair 340]

If you want a preview, just get an old Atom-based netbook and see how easy it is to cross compile onto that.  I don't think it will be trivial on something like Debian, which has a penchant for using dynamic libraries.  Frankly, I would expect that it's not going to be markedly simpler than using ARMv7a, with the exception that your BeagleBone will compile faster when compiling on the target.  When I ported OpenCV 2 to armv7a-neon in 2010, it took about 40 minutes to compile the whole thing on the test target, which at that time was a 750 MHz BeagleBoard (I think C4).  When I cross-compiled it on a Quad Core-i5, I seem to remember it took about 5 or 6 mins.  40 mins isn't really a big deal if you're doing it just once.

[yyrkoon 250]

JP. anyways, I have no idea how much hands on you've had lately with this sort of thing. But I do know that I have had lots of hands on with Linux on ARM over the last few months. I have also had more than usual ( for me ) hands on with Linux on x86. Some virtual machines, and some physical hardware. Luckily for me, I have years ( around 15 maybe a few more ) worth of experience with Debian. Also luckily for me, Debian runs really well on the hardware I am working with now ( Beaglebone black - Much thanks to Robert C Nelson ).

 

The point I am trying to make here is that with x86 virtual machines, and semi modern hardware. I can find guides for the things I am not familiar with and make it work. Sometimes, it is a minor chore, as some instructions may not be up to date. There can also be diffferences between older versions, and what you're using now. Squeeze vs Wheezy for instance has several differences. However, the key here for me at least is that the distro is used by many, and the documentation is top notch( debian.org )

 

On the ARM side of things, Debian works very well also. There are not as many packages available as are on the i386 release, but what is there is very solid. With that said, it was a good bit of work getting Nodejs ( for example ) working on my own ARM platform. The github latest guide failed to build on my Beaglebone Black. So instead of giving up, I did a days worth of searching and found a guide that had one single compiler flag that allowed me to compile. Since I had zero experience with compiling Nodejs, you can expect that this was a bit annoying. Ok, so it is free software . . . so not really complaining, but it is also not exactly the experience people are used to on x86(i386). Then the npm module manager issue i mentioned above was rather hilarious. Until it came time to try and remove all that crap without any issues.

 

There are also other various issues that I ran into that were rather annoying too. However, being a long time user of Debian, I was able to work around this issues much easier than say someone new to the distro.

 

Also for what it is worth I have an Acer one ( N550 atom netbook ) here that I am fixing up for a friends son. This has been the same experience as any other x86(i386) install of Debian that I have done countless times. Everything works as I expect it to. 

[yyrkoon 250]

If you want a preview, just get an old Atom-based netbook and see how easy it is to cross compile onto that.  I don't think it will be trivial on something like Debian, which has a penchant for using dynamic libraries.  Frankly, I would expect that it's not going to be markedly simpler than using ARMv7a, with the exception that your BeagleBone will compile faster when compiling on the target.  When I ported OpenCV 2 to armv7a-neon in 2010, it took about 40 minutes to compile the whole thing on the test target, which at that time was a 750 MHz BeagleBoard (I think C4).  When I cross-compiled it on a Quad Core-i5, I seem to remember it took about 5 or 6 mins.  40 mins isn't really a big deal if you're doing it just once.

 I have a netboot / cross compiler setup on a VM and on this netbook I have now. Standard x86(i386) install. That is, my beaglebone black can netboot from either one of my VM's another laptop I have, plus this netbook I am working on. It's all the same.

[jpnorair 340]

...So instead of giving up, I did a days worth of searching and found a guide that had one single compiler flag that allowed me to compile...

We've all been there.  

 

Anyway, FPU is always going to be more of a pain point.  If Quark is using i386 FPU, it will be well-supported but mostly useless for actual calculations.  So, always a pain point.

[yyrkoon 250]

Indeed ! I myself have been there many times. Sort of starting to think of it as standard operating procedure. Anyways, it is not all that bad, usually all issues can be resolved with a bit of time invested. Mono ( .NET ) is one i have not yet solved for Linux on ARM, and now that I have Nodejs, I am not sure I need / want to solve that issue any more.

 

So now you have me wondering if Quark will be similar to Italium compared to X86 JP . . .

[jpnorair 340]

So now you have me wondering if Quark will be similar to Italium compared to X86 JP . . .

Probably more like Atom.  The small amount of info I have on Quark shows that it is similar in a lot of ways to Atom, not just in the choice of naming.  Itanium is entirely different than x86, a completely different architecture.  In some ways it's more RISC, actually, than any other modern RISC designs.  It's a very elegant piece of work, and it's a shame Intel can't find ways to bring it to the mainstream.