Raspbian Jessie (64bit) for RPi3?

[jahboater]

Thanks for this post

That was a long time ago: Oct 07, 2016, there are better options now!

[jamesh]

I understand that backward compatibility is very important

Only to those people who looks backwards.
To people who look forwards 32bits is not the future.

Well how much penetration does RPF have in the Education market?
Mainly UK and early adopters in other countries. <0.1% of world schools?
How many of UK schools are using Pi and how many actually care about 32 or 64 bits?

Thanks for your estimate of the RPFs < 0.1% penetration in the world education market.

It is true that most schools don´t care about 32 / 64 bits but they do care about smooth and timely OS updates: if 64 bits help there than that is a huge plus.

64 bits = no difference whatsoever to educational market. There are very few areas, if any, where you NEED a 64 bit device/OS. Any and all teaching, TBH, could be done in 8 or 16 bits.


Are you aware that the OS is constantly being updated? Like every day? However, we release full Raspbian much less freqwuently, but if you want to you, you can have updates to yourOS every single day!


And for all those people decrying the emphasis on backwards compatibility, sorry, that ain't gonna change! Even now, we are releasing new models that are 32 bit only (The Zero and Zero w are both Armv6 devices and 32 bit only
), so maintaining that backwards compatibility is absolutely VITAL!

Better performance with 64bits? Yes, a little bit. Not as much as people think though. Just using the A53 cores gives 32 bits a boost, which is why that approach was taken. But you want REAL performance? Write node in NEON assembler . And that can work in 32 and 64 bits OS's.

[rplantz]

64 bits = no difference whatsoever to educational market. There are very few areas, if any, where you NEED a 64 bit device/OS. Any and all teaching, TBH, could be done in 8 or 16 bits.

This depends on which education market. As I noted above, my university uses the RPi to teach introduction to computer organization. Most of the class is about the instruction set architecture, i.e., assembly language. We would prefer that our students learn AARCH64 because (a) that segues more nicely with the textbook (Patterson & Hennessy) used in the subsequent class and (b) they will be more apt to encounter AARCH64 in their future careers.

Yes, teaching could be done in 8 or 16 bits. In principle, it can even be done in 4 bits (Intel 4004). But I have found students to be much more engaged when we use "real world" systems. And I thought this was the primary motivation of creating the Raspberry Pi in the first place --- to get young people engaged. They are also aware that listing 64-bit ARM assembly language on their resumes is better than, say, Intel MCS-96.

[fruitoftheloom]

64 bits = no difference whatsoever to educational market. There are very few areas, if any, where you NEED a 64 bit device/OS. Any and all teaching, TBH, could be done in 8 or 16 bits.

This depends on which education market. As I noted above, my university uses the RPi to teach introduction to computer organization. Most of the class is about the instruction set architecture, i.e., assembly language. We would prefer that our students learn AARCH64 because (a) that segues more nicely with the textbook (Patterson & Hennessy) used in the subsequent class and (b) they will be more apt to encounter AARCH64 in their future careers.

Yes, teaching could be done in 8 or 16 bits. In principle, it can even be done in 4 bits (Intel 4004). But I have found students to be much more engaged when we use "real world" systems. And I thought this was the primary motivation of creating the Raspberry Pi in the first place --- to get young people engaged. They are also aware that listing 64-bit ARM assembly language on their resumes is better than, say, Intel MCS-96.

Rather than wishing for something, which may or may not happen sometime in the future.

Use an AArch64 Linux Operating System which is available today

[jahboater]

(b) they will be more apt to encounter AARCH64 in their future careers.

They are also aware that listing 64-bit ARM assembly language on their resumes is better than, say, Intel MCS-96.

Of course - it is the future.

I think its probably a bad idea to teach A32. There are a number of features that are a) unique or uncommon on other ISA's, and b) do not work well with modern (out-of-order) processors (including the more recent higher performance ARM CPU's). They have been removed from AARCH64 for good reason.

[rplantz]

Rather than wishing for something, which may or may not happen sometime in the future.

Use an AArch64 Linux Operating System which is available today

Yes, I'm looking. One of the nice things about Raspbian is its stability and ease of use. From my very limited investigation of the others, they are not quite there yet.

More to the point, I see my use of Raspbian as being within the primary mission of the whole Raspberry Pi project in the first place --- get young people engaged. Raspbian is easy for them to use, and my textbook takes them into using the command line in a terminal window, etc. From this point of view, I think that a 64-bit version of Raspbian is a natural extension of the Raspberry Pi mission.

[fruitoftheloom]

Rather than wishing for something, which may or may not happen sometime in the future.

Use an AArch64 Linux Operating System which is available today

Yes, I'm looking. One of the nice things about Raspbian is its stability and ease of use. From my very limited investigation of the others, they are not quite there yet.

More to the point, I see my use of Raspbian as being within the primary mission of the whole Raspberry Pi project in the first place --- get young people engaged. Raspbian is easy for them to use, and my textbook takes them into using the command line in a terminal window, etc. From this point of view, I think that a 64-bit version of Raspbian is a natural extension of the Raspberry Pi mission.

Quite so but unlikely to happen for the next Educational Year UK September.

Arch Linux Arm
Suse
Fedora 25
CentOS 7

[timrowledge]

I think its probably a bad idea to teach A32.

Well despite the fact that I'm substantially in sympathy with your interest in AArch64 etc, I would point out that there are around a gazillion(*) ARM32 systems out there that are likely to be part of the world of students going into the not-desktop software arena.

(*)Gazillion - a technical term meaning an awful lot, like really a yuuuuge number, many, many, many, like the sort of number you might get by filling a dozen Wembley stadia with Smarties. More strictly speaking for ARM, something like 80,000,000,000.

[jahboater]

I think its probably a bad idea to teach A32.

Well despite the fact that I'm substantially in sympathy with your interest in AArch64 etc, I would point out that there are around a gazillion(*) ARM32 systems out there that are likely to be part of the world of students going into the not-desktop software arena.

Yes of course thats true, and it will continue to be true for a long time - much longer than in the Intel world. But my guess is that A32 will, in time, decline, and A64 will, in time, grow.

My other concern was with students getting reliant on features such as "most instructions being conditional", or being able to write random values to the PC, or ldm/stm, and so on. They will get a rude shock when they move to x86, or A64, or other ISA's, where that sort of thing is not possible. These (popular) features have been removed by ARM because they don't work with modern processors, and are not available on other platforms, so why teach them?

[rplantz]

My other concern was with students getting reliant on features such as "most instructions being conditional", or being able to write random values to the PC, or ldm/stm, and so on. They will get a rude shock when they move to x86, or A64, or other ISA's, where that sort of thing is not possible. These (popular) features have been removed by ARM because they don't work with modern processors, and are not available on other platforms, so why teach them?

Thank you, jahboater, for bringing this up. I should go through my current (32-bit) book and do a better job of pointing out the differences between AARCH32 and AARCH64. In particular, I should rewrite any examples I have that use conditional execution. It gets a bit tricky, because the gcc compiler generates AARCH32 code. In my book, I discuss programming concepts by first showing the C construct, then what the compiler generates, then my assembly language solution. The point of my book is not to teach assembly language as a way to create apps, but as a look "under the hood" when writing code in a high-level language.

[plugwash]

I think its probably a bad idea to teach A32.

Well despite the fact that I'm substantially in sympathy with your interest in AArch64 etc, I would point out that there are around a gazillion(*) ARM32 systems out there that are likely to be part of the world of students going into the not-desktop software arena.

True, a lot of the code on said systems will be "T32" not "A32" though.

[rplantz]

I think its probably a bad idea to teach A32.

Well despite the fact that I'm substantially in sympathy with your interest in AArch64 etc, I would point out that there are around a gazillion(*) ARM32 systems out there that are likely to be part of the world of students going into the not-desktop software arena.

True, a lot of the code on said systems will be "T32" not "A32" though.

Excellent points. I always point out to students that their first job will almost certainly be working on somebody else's code, not creating their own new app.

[jamesh]

As someone who learn 6502 assembly language on a Apple ][, and who has been a Windows programmer (C/C++), then embedded (8051 assembler), then embedded C, then embedded Linux, then Pi (over 30 years working without gaps of > 2 months), I have rarely needed to to write assembler. In general it is a very specialised area. I agree that assembler should be taught, because it give huge insights in to how higher level language work (and can be debugged), but to specifically require A64 rather than A32 or even x86 seems unnecessary. Teach the basics of low level instructions, of caching, of pipelineing. None of which are overly bit depth specific.

Note that the huge majority of ARM systems out there are 32 bit or Thumb based, or even M series, and there is one huge elephant in the room with going to A64 and that is power consumption. If you want to keep the power consumption down, you are not going to be running A64. Or even A32. IoT devices need low power consumption which means smaller instructions, and also possible use of assembler to improve performance on these lower spec devices!

[jahboater]

but to specifically require A64 rather than A32 or even x86 seems unnecessary.

Thats not what I said; it was more a suggestion to possibly exclude A32 only - because it has features that are not available on other processors. Students would have to re-learn much when they move to another platform. Nothing at all to do with the bit depth.

Of course there are billions of A32 or T32 machines out there so it will always be useful.

I have rarely needed to to write assembler. In general it is a very specialised area. I agree that assembler should be taught, because it give huge insights in to how higher level language work (and can be debugged)

Definitely.
The only time I have needed assembler at work in decades was for IBM mainframes!

[jamesh]

but to specifically require A64 rather than A32 or even x86 seems unnecessary.

Thats not what I said; it was more a suggestion to possibly exclude A32 only - because it has features that are not available on other processors. Students would have to re-learn much when they move to another platform. Nothing at all to do with the bit depth.

Of course there are billions of A32 or T32 machines out there so it will always be useful.

I have rarely needed to to write assembler. In general it is a very specialised area. I agree that assembler should be taught, because it give huge insights in to how higher level language work (and can be debugged)

Definitely.
The only time I have needed assembler at work in decades was for IBM mainframes!

In general students would have to learn a completely different stuff whenever they move between processors (x86->ARM->MIPS etc). That learning process is there whatever the first platform you learn is. It's the concepts that are important, not the syntax or the idiosyncrasies.

[rplantz]

Excellent points by jamesh and jahboater. If you read the short Preface to my book, http://bob.cs.sonoma.edu/IntroCompOrg-R ... eface.html, I think you will see that I agree with your philosophy. You're right that moving to a different environment means learning new things, and that the main thing is to understand the principles.

I've done several things in the book to help students learn the variations in ARM. For example, when I describe an instruction, I use the notation used by ARM spec sheets. I urge students to also read the spec sheet in parallel with the book's explanation, which will help them to learn how to read it.

I guess I should back off from my push for 64-bit Raspbian. I'm going through my book now and finding plenty of typos and clumsy wordings to keep me busy for awhile.

[Jim Manley]

Greetings to the assembled masses here (pun fully intended for the low-level coders). My buck-two-eighty's worth (two cents adjusted for inflation since my inception ) opinion on 64-bit needs requires putting on my (one of many) hat as senior docent at the Computer History Museum in Silicon Valley. I just wanted to remind everyone that, if you really need to do things at the speed of heat (literally), ARM/RISC is not going to cut it, no matter how much you may want to promote it. Performance is the advantage of CISC, but at the cost of a lot of power consumption and heat generation.

If power consumption and heat are the bane of your application though, along with weight and volume (e.g., mobile, remote, etc.), then ARM/RISC is the way to go. There is no one "best" hardware or software solution for all problem domains - sometimes, a four-bit processor running some binary code is all that's needed (e.g., a stop light, simple microwave oven, IoT sensors, etc.). Compared with what most people actually need, high-performance computing has become a niche with about as many different architectures as there are applications.

I spend a lot of time teaching students and educators (not just in computing, but engineering, mathematics, sciences, and even humanities) that bigger is not always better, faster is often better achieved through design than reaching for a bigger (more expensive) hammer, and inefficient code can bring any level of hardware to its knees in no time. There's a lot of wheel reinvention that's occurred over time as young turks come along every year with no understanding that what they're trying to do has usually already been encountered and solved by someone else.

That's why we have museums and educational institutions, although I've found shocking lack of awareness in the latter of what's come before. One of my favorite tours to give in the museum shows how the same problem was solved over and over again by people who didn't think to look at what was done before, and hence repeated development of technological cul de sacs in the exact same old neighborhood.

Arduino and continued use of other 8-bit microprocessors operating in single-digit MHz clock speeds amply demonstrate that using the right tool for the job is critically important (even variants of the 6502 jamesh and I cut our teeth on are still in production). We haven't even come close to exhausting the power in 32-bit systems, and there are very few applications where doubling word size will result in proportional improvements in performance if the underlying system design is inefficient.

When symmetric multiprocessing systems first came along in the late 1970s, the US Department of Defense (a primary early user) commissioned a study to find out how steep the learning curve was for software developers transitioning from single-processor systems. Only about one third of those evaluated were able to make the mental leap required when trying to keep track of what's going on in multiple processors operating on shared memory at the same time. It's become a much smaller fraction in today's attention-deficit addled population, which is why most massively-parallel systems are running SIMD (single-instruction, multiple data) and not MIMD (multiple-instruction, multiple data) today. The latter is much more difficult to design for properly, so few master it.

I'm not saying that we shouldn't use 64-bit OSes on our 64-bit hardware, I'm just pointing out that it's going to remain a niche and that 32-bit systems will be around for a very long time (the mobile market), just as 8-bit is still quite appropriate for many tasks, especially with the advent of IoT. For those who may have forgotten, around 99% of the die area of a Pi SoC is for the GPU - the CPU(s) are almost an afterthought and are primarily data traffic cops, at least in the original Internet streaming media application for which the SoCs in Pii were designed.

We now return you to your life, already In progress!

[bstrobl]

In general students would have to learn a completely different stuff whenever they move between processors (x86->ARM->MIPS etc). That learning process is there whatever the first platform you learn is. It's the concepts that are important, not the syntax or the idiosyncrasies.

While that is true, it does introduce an overhead which might keep others from experimenting if they have to learn another architecture. If for example your university teaches MIPS, you might be less inclined to learn ARM since it might become a liability to do so during the semester, especially if 32 bit ARM is on the way out.

If we want a platform for others to produce highly optimised software for, the most sensible thing would be to give a single future proof ISA to target. Since all the phone manufacturers and corresponding developers as well as those in the compiler community are moving to ARMv8, that would make sense.

I am not saying ditch 32 bits now or within 3 years, just that there should be a roadmap to slowly wean off of it. Else the cold reality might set in once everyone else has gone 64 bit only that no recent software will continue running on ARMv7. Part of the appeal of the Pi is being able to run a standard Linux distribution, but that will only last as long as those continue delivering compatible packages.

[fruitoftheloom]

Considering the forthcoming Debiian Stretch will have a 2-3 year lifespan and 5+ if LTS is supported then ARMHF Aarch32 will be around a few more years...

....whereas Aarch64 ARM64 Debian is still work in progress:

https://wiki.debian.org/Arm64Port

[jahboater]

....whereas Aarch64 ARM64 Debian is still work in progress:

This page contains details about the port of Debian to the 64-bit ARM platform (arm64), known in some other places as AArch64. This port was released for the first time with Jessie (Debian 8).

Also, I am happily running aarch64 Ubuntu, and have been for a long time, which I thought was based on Debian?

I suppose the Pi4, if it is to be competitive, may have more memory - which will trigger a 64-bit OS as it has for the other 2GB ARM sbc's.

[fruitoftheloom]

....whereas Aarch64 ARM64 Debian is still work in progress:

This page contains details about the port of Debian to the 64-bit ARM platform (arm64), known in some other places as AArch64. This port was released for the first time with Jessie (Debian 8).

Also, I am happily running aarch64 Ubuntu, and have been for a long time, which I thought was based on Debian?

I suppose the Pi4, if it is to be competitive, may have more memory - which will trigger a 64-bit OS as it has for the other 2GB ARM sbc's.

Yes Ubuntu starts with Debian code base, but Canonical further develop as they see fit..

Is your Ubuntu flavour Canonical Supported or is it a Community Supported effort like Armbian ??

Where is a fully working .IMG available from ??


.

[jahboater]

Is your Ubuntu flavour Canonical Supported or is it a Community Supported effort like Armbian ??

Its for the Pine 64 and the Odroid C2 (which is the only one I now use). I presume its maintained by hardkernel themselves.

Where is a fully working .IMG available from ??
http://odroid.com/dokuwiki/doku.php?id= ... nux_ubuntu
Its for the C2, it wont run on the Pi. They sell eMMC cards and uSD cards with it pre-installed as well.

[fruitoftheloom]

Is your Ubuntu flavour Canonical Supported or is it a Community Supported effort like Armbian ??

Its for the Pine 64 and the Odroid C2 (which is the only one I now use). I presume its maintained by hardkernel themselves.

Where is a fully working .IMG available from ??
http://odroid.com/dokuwiki/doku.php?id= ... nux_ubuntu
Its for the C2, it wont run on the Pi. They sell eMMC cards and uSD cards with it pre-installed as well.

OK so absolutely nothing whatsoever to do with Raspbian Jessie Aarch64 running on a Raspberry Pi with the BCM2837 SoC, so really a bit pointless in this thread ??


As you like mentioning other SBC's -Armbian offer a Aarch64 release for your boards

[davep]

As a bit of an aside, there is a 64-bit OpenBSD OS available for the Pi 3 https://www.openbsd.org/arm64.html

http://undeadly.org/cgi?action=article& ... &mode=flat

[Mr.Scoville]

If power consumption and heat are the bane of your application though, along with weight and volume (e.g., mobile, remote, etc.), then ARM/RISC is the way to go.

Jim,

your post has been quite refreshing. At least to me, not being an Assembly (punch intended ) blessed by the Californian sun, but "back then"(TM) wasting his time diving into 6502 Assembler language to beat some sounds out of an Apple ][+.

Yet, I want to dare your statement. Why? Because: KISS. The single most important rule each and every software developer-to become has not just to learn, but to digest, to get assembl... assimilated by before they call themselves software developers. Simply put: If you need 1 bit, use 1 bit. If you need 4 bits, use 4 bits. If you need 128 bits, use 128 bits. In other words: If the stuff you've learned doesn't solve your current problem, don't try to hunt the beast down and bash it with what you've learned until it stops twitching, but adjust and refine your knowledge. To get the state of a simple button, you need exactly 1 bit. You won't even need an Arduino Nano to turn a darn bulb on.

IMHO the reason why the RPi3 is there is because some very innovative people have found out that to some common demands, it is a perfectly fitting and affordable solution.

Following the KISS principle, I am absolutely aware of the point that the less tools you need to solve a problem, the better the solution will be (kind of Ockhams' Principle, if you wish). But that doesn't mean that more bits are more effective. If you stick to the KISS principle (and you ought to!), there is no "eierlegende Wollmilchsau" (a German figure of speech, kind of the Swiss Army knife). Reinventing the wheel has always been a waste of time and energy. But reducing your real needs to exactly match the problem has always been a good idea.

I am absolutely certain that, for some hands full of bucks, many companies would be glad to give the 64 Bit demanders what they want: AArch64, NANO, whatnot. But to those of you who are like "I want it now, and I want it for free!"... Are you keeping in mind what the initial idea was? And, in a way, still is? Provide computing power to a huge crowd! In a pretty well documented manner, because there's Linux running on that little piece of hardware.

If you really need computing power to the max, buy yourselves a container full of graphics boards. The consumer market has nothing faster to offer than GPUs. Plug them on fast Intel-based boards, use something like Wolverine for load balancing and controlling. This is how the big guys do it.
If you need warp speed data transfer performance, there are other solutions out there. Some have been mentioned in this thread, like the Odroid C2.

Get familiar with it, demanders: getting familiar with the problem, and with the possible solutions might me the first and most important step to solve the problem.

It is, in most cases I've become aware so far in this thread at least, not about more, more and even more GHz and bits. It is focusing the problem to find the most appropriate solution.

As you said, Jim:

There is no one "best" hardware or software solution for all problem domains - sometimes, a four-bit processor running some binary code is all that's needed (e.g., a stop light, simple microwave oven, IoT sensors, etc.). Compared with what most people actually need, high-performance computing has become a niche with about as many different architectures as there are applications.

'nuff said. ^^