Why is nobody implementing ARM Cortex MCU's in their projects?

[MK14]

My understanding is that there is a team of 60 people, who are working full time on the Raspberry PI project. Under the employ of the Raspberry PI foundation.

The Raspberry Pi 3 has been out for a year now, with a 64 bit cpu. There is still not a supported 64 bit OS for it! You're limited to treating it as a slightly faster Pi 2 with regular old ARM 32 software (and actually I found that both Mono and CoreCLR run faster on the Pi2 than on the Pi3).

I did not realize that 64 bit OS's were not available for the Raspberry PI3. I'm speculating, but would guess that it is needing to exceed 2/4 Gb of Ram, is what especially pushes people to want/need the 64 bit mode. Even though it has other advantages as well, such as speed and integer maths precision.

So when they want the Raspberry to come with more than 4 Gb of Ram, e.g. 8 Gb (in some cases 2 Gb is the limit, because the 32 bits is signed and/or other reasons). Then it will be vital (unless a horrible memory expansion scheme is used) to have a proper 64 bit OS, in order to use all the available on-board ram.

Hopefully at some point, 64 bit "PCs", based on 64 bit Arm chips, will become much more commonplace in the future. Then proper 64 bit Arm OS's are likely to follow. I think they are already available (I assume), but not used much as the hardware is not common yet (except on mobile phones and some notepads).

[julianhigginson]

64 bit OS is common for desktop linux, and even some other A53 based embedded linux boards already have 64 bit linux available.... But something major seems to be holding back the Pi. I guess it's something to do with drivers for the peripherals, but, really, no idea why they are having such a hard time making a 64 bit OS.

I also have a love-hate with linux. I can't use it for my daily computing environment (mostly because stuff like Altium doesn't run on it) but do use it for compilers and embedded system development... I also tend to find that I spend a fair bit of time hacking about just to make something work. Not so much at the getting started point, my experience of modern linux is it's mostly plain sailing, but the issue for me, is once I have something working, eventually something weird happens and I have to drop what I'm actually wanting to do, go into research mode. then I find the answer, and it's good again, till the next weird thing... And most of these weird things are caused by tribalism and so many different people with huge tech egos all building stuff their own way rather than building stuff to just work with everything else.

I imagine that if you love tinkering with computers, linux is probably fun (as long as you're not on a deadline) but I'd rather have my embedded computer and its standard services just work, and spend my time making useful things with it... I'm not 100% sure embedded linux is there yet, as amazing as it is, and as much as you get for free when you use it...

[Monkeh]

something major seems to be holding back the Pi.

Compatibility with all the precompiled software and horribly badly written scripts by people with no concept of mixed userspaces. IOW, everything people like about the Pi.

[nctnico]

I imagine that if you love tinkering with computers, linux is probably fun (as long as you're not on a deadline) but I'd rather have my embedded computer and its standard services just work, and spend my time making useful things with it... I'm not 100% sure embedded linux is there yet, as amazing as it is, and as much as you get for free when you use it...

Embedded Linux is the defacto standard. Look at all the routers, setop boxes, VOIP phones, mobile phones (billions of them!), PABXs, test equipment, etc, etc running Linux. However, getting yourself up to speed to deploy Linux in an embedded environment takes a serious amount of effort to learn. You can't become a brain surgeon overnight either.

[julianhigginson]

Embedded Linux is the defacto standard. Look at all the routers, setop boxes, VOIP phones, mobile phones (billions of them!), PABXs, test equipment, etc, etc running Linux. However, getting yourself up to speed to deploy Linux in an embedded environment takes a serious amount of effort to learn. You can't become a brain surgeon overnight either.

LOL... sure... huge multinational enterprises with entire divisions setup to just keep linux under control manage to do it so it must be possible for anyone as long as they are a genius and completely perfect in every way and have nothing else important to do, and if they can't well they must just be lazy failures and terrible engineers. right.

Plenty of other OSes manage to just work... you set them up once, and you perform updates as software packages upgrade, and generally, things just keep running.

With linux, you set things up again and again, over and over. Often you need to update something and find out there's something else that needs changing to keep compatibility. This happens with my compiler VMs, and it happens with embedded linux installs. Yes with effort I  can always sort it out, but what it is, is an unnecessary waste of time compared to how things could be if everything was just developed to work.

And it makes having a linux based product a continuing project. You can't just hand over a linux based product that's "finished" for all intents and purposes to operations, being manufactured and shipped and customer supported... If you have a linux based product out in the world you always need some resource who knows everything about the kernel build and all the modules, who can adjust/rebuild whenever a major problem is discovered, and fix anything whenever the updates break something. And we're not talking about the application code, but a standard basic platform that you just want to run the application on!

Linux gives so many features and possibilities, but at the same time it adds so much inertia to the products it enables. This is why we have a massive embedded linux botnet problem now.

Yes you can offload the responsibility to one of the embedded linux providers, and that will save a lot of time and work for a small team, but then you're limited to what kind of hardware they support, and dependent on them forever, and always hoping that any particular problem you have with whatever packages you particularly need to run on it is significant enough to make them want to fix it in a timely manner...

[james_s]

Have you ever even used a flavor of embedded linux? Your post makes me think not. Why would you set it up over and over? I set up my raspberry pi as a general purpose web and FTP server with temperature monitoring and an RTL SDR dongle several years ago and it's just worked ever since. The only time it's ever gone down is during power outages or a few times when I added something else to it. It just works, and what other choices are there? Some of the machine tools at my friend's shop run WinXP embedded and it's a pain in the butt from a relative standpoint. Linux just works, in the embedded field it's a very mature product that is used practically everywhere in products from companies of all sizes. My router is a commercial product but I run an open-source firmware on it that works much better than what came on it.

At my day job I work with embedded linux and we spend our time on the application level and user interface, the base OS only changes to support new hardware platforms.

[westfw]

Please enlighten me: what's the point of a 64bit OS on a system with a hard limit of 1G of memory?
Isn't the OS-level functionality of "64bit" almost exclusively associated with managing more than a 32bit address space?
RPi can't have more memory than that, and you really don't want it to page/swap to alternate storage, either...

[Monkeh]

Please enlighten me: what's the point of a 64bit OS on a system with a hard limit of 1G of memory?
Isn't the OS-level functionality of "64bit" almost exclusively associated with managing more than a 32bit address space?
RPi can't have more memory than that, and you really don't want it to page/swap to alternate storage, either...

If you're doing any math involving larger than 32-bit numbers, it helps a lot.

[westfw]

If you're doing any math involving larger than 32-bit numbers, it helps a lot.

Ah.   I see.  I was assuming that there would be cascaded registers like x86 or something, so 64bit math would be possible whether or not the operating system was 64bit.   But ARM does a whole "execution state" thing where you only have the 64bit instructions when you're operating in the AArch64 state, and you can't have an AArch64 user process with a 32bit OS.  Sort-of ugly and annoying, actually...

There are times when you must change the execution state of your system. This could be, for example, if you are running a 64-bit operating system, and want to run a 32-bit application at EL0. To do this, the system must change to AArch32. When the application has completed or execution returns to the OS, the system can switch back to AArch64. Figure 3.7 shows that you cannot do it the other way around. An AArch32 operating system cannot host a 64-bit application.

( https://developer.arm.com/docs/den0024/latest/3-fundamentals-of-armv8/33-changing-execution-state )

[Dijital]

Have you ever even used a flavor of embedded linux? Your post makes me think not. Why would you set it up over and over?

Sure if you set up an embedded system and get it to its final state, then it will work great for years. I think the difficulty he is talking about, and the difficulty I have experienced, is when you need to make changes/adjustmants. Obviously it's easier when you have tens of thousands of hours of experience working with linux/embedded linux. However when you are someone who just wants a few things to work, and has no interest in learning the entirety of linux, it is often a daunting and time consuming process. I have used linux on and off for about a decade, mainly desktop but some embedded too, and probably have 500 hours collectively using it over that time. I still feel like I have idea what is going on when using it and constantly have to rely heavily on the internet or just give up on what I was trying to do.

[Kjelt]

If you use it for yourself on a closed inhome network and get it running so you are satisfied, yeah you can probably let it run for years without any problem.
If you use it as a public internet facing device, even one port, oh man you better make sure you update the libs every week, keep logs of who is knocking on your ports and what they are doing and be an expert on the matter.
People that say that they do not have to update their embedded Linux public internet facing device have absolutely no clue what they are doing. Too many raspberri pi camera projects out there of amateurs that will be used in DOS attacks and it won't suprise me if in a few years legislation will lay the responsibility of having your systems up to date with the owner of the device.

[nctnico]

If you use it for yourself on a closed inhome network and get it running so you are satisfied, yeah you can probably let it run for years without any problem.
If you use it as a public internet facing device, even one port, oh man you better make sure you update the libs every week, keep logs of who is knocking on your ports and what they are doing and be an expert on the matter.
People that say that they do not have to update their embedded Linux public internet facing device have absolutely no clue what they are doing. Too many raspberri pi camera projects out there of amateurs that will be used in DOS attacks and it won't suprise me if in a few years legislation will lay the responsibility of having your systems up to date with the owner of the device.

But still you have to be sensible: only run the bare minimum amount of software and only fix what is broken. If you are going to update everything to the latest version then you'd be creating a new board support package for every minor update and that will be a lot of work. Over a decade ago I maintained a couple of Linux based web servers. Ofcourse I subsribed to a mailing list which announced security updates. 99.99% of those (daily) messages didn't apply to the servers I maintained and patched versions of the software versions already running where available.

[Kjelt]

But still you have to be sensible: only run the bare minimum amount of software and only fix what is broken.

Yes correct, part of the "hardening" process should be to disable and/or remove any unneeded modules, ports and services.
How many people that buy a RPI and hang it on the internet do you thing know that or do that? It will be scary to see how many RPI's there are connected to the internet with ssh enabled with the default password.

[donotdespisethesnake]

Embedded Linux is the defacto standard. Look at all the routers, setop boxes, VOIP phones, mobile phones (billions of them!), PABXs, test equipment, etc, etc running Linux.

Yes, and now all that equipment has huge security problems. Also webcams, printers, home thermostat, light bulbs. Yes, your printer can take part in a DDOS attack   

Obviously, this is not the fault of Linux, but the fault of badly configured Linux. But that is the point, embedded Linux is hard to get right. You can't just drag and drop a desktop OS onto things like these guys do, and then hope for the best.

The same would apply if Windows was used in embedded devices.

[tszaboo]

Have you ever even used a flavor of embedded linux? Your post makes me think not.

Sure. You only need to do the following to have your experience compared to us:
Design a board, with DDRx memory
Change stuff in UBOOT
Change stuff in kernel
Customize the distro that you have
Add custom programs to the distro
Build it, bebug it
Update the kernel 2-3 times because they found security holes the size of the moon
Write (hardware) test scripts,
software patch release system for simultaneously updating multiple systems

Doing stuff with the rPi is not comparable. They made the system, that even a 12 year old can use. So congratulations for comparing project blinky to the moon landing.

[james_s]

If you use it for yourself on a closed inhome network and get it running so you are satisfied, yeah you can probably let it run for years without any problem.
If you use it as a public internet facing device, even one port, oh man you better make sure you update the libs every week, keep logs of who is knocking on your ports and what they are doing and be an expert on the matter.
People that say that they do not have to update their embedded Linux public internet facing device have absolutely no clue what they are doing. Too many raspberri pi camera projects out there of amateurs that will be used in DOS attacks and it won't suprise me if in a few years legislation will lay the responsibility of having your systems up to date with the owner of the device.

What is the alternative though? Windows embedded? It's not as if that's any more secure. For any system based around a general purpose operating system if it's exposed on the internet it's going to have to be set up sensibly and updated occasionally. I update my rpi's somewhat regularly but that's just running apt-get to update the packages, it's not like I have to go through all the setup or spend hours tinkering. Updating is as painless as my Windows laptop except I don't generally have to worry about the OS provider slipping in malware and crapware as Microsoft has recently become infamous for doing.

[Monkeh]

If you use it for yourself on a closed inhome network and get it running so you are satisfied, yeah you can probably let it run for years without any problem.
If you use it as a public internet facing device, even one port, oh man you better make sure you update the libs every week, keep logs of who is knocking on your ports and what they are doing and be an expert on the matter.

Or, instead of blindly updating 'weekly' and introducing problems, you could determine what actually needs security fixes and introduce.. only security fixes.

Nah. Too easy to think about it. Just update all the things and complain it breaks.

[nctnico]

it won't suprise me if in a few years legislation will lay the responsibility of having your systems up to date with the owner of the device.

I think so too but I'm wondering how that would be implemented legally and practically. In the EU it likely becomes part of the CE (self) certification but the biggest question is how the tests and requirements are defined and how long updates are to be made available. Either way it will have a huge impact on manufacturers of all kinds of devices.

[Kjelt]

Practically if your ip address was part of a DOS attack or other attack, your ip address would get on a blacklist , probably by your internet provider who gets a complaint.  Perhaps if you remove the offending device and be retested you are cleared again. 

[Kjelt]

Or, instead of blindly updating 'weekly' and introducing problems, you could determine what actually needs security fixes and introduce.. only security fixes.

Nah. Too easy to think about it. Just update all the things and complain it breaks.

Yes if you are one in a thousand that knows their stuff. Honestly I don,t know exactly which parts need to be updated and which do not on a linux distro, there is a need for a maintenance team perhaps with some subscription fees. Vulnerability reports are made on almost a dayly basis, do you have time to read them all? Do you have time to figure out which of the 100+ packages need an update? I like to compare it to for instance the Synology DSM solution, they have a team and continuously produce updates for bugs and new security vulnerabilities. The NAS can install it automatically. This works for people.

[nctnico]

Practically if your ip address was part of a DOS attack or other attack, your ip address would get on a blacklist , probably by your internet provider who gets a complaint.  Perhaps if you remove the offending device and be retested you are cleared again. 

This is already done by some internet providers if they detect you have a heavely infected PC (or other device) connected to internet. Still blacklisting needs to be done with care because doing it too rigorously can cause more problems than it solves and it can be used as a means of a DOS attack.

Yes if you are one in a thousand that knows their stuff. Honestly I don,t know exactly which parts need to be updated and which do not on a linux distro, there is a need for a maintenance team perhaps with some subscription fees. Vulnerability reports are made on almost a dayly basis, do you have time to read them all? Do you have time to figure out which of the 100+ packages need an update?

As I wrote before: if a device is sensitive to security then you'd typically know or have a list with installed software + versions. The amount of software which runs should be minimal so checking this list against a security bulletin takes a minute at most. 99.9% of the security bulletins won't affect a device anyway.

[brucehoult]

Please enlighten me: what's the point of a 64bit OS on a system with a hard limit of 1G of memory?
Isn't the OS-level functionality of "64bit" almost exclusively associated with managing more than a 32bit address space?
RPi can't have more memory than that, and you really don't want it to page/swap to alternate storage, either...

Plenty of reasons...

- doing something where 64 bit integers is the performance limiter

- doing something where more than 16 registers avoids memory spills (well, 11 or 12 really)

- putting things at random places in a large address space for security, even if you're using less than 4 GB (or 1 GB) total

- developing software for other Aarch64 devices with more memory but less convenient to work on (I recently used an Odroid C2 to develop a linux kernel extension for my company's 64 bit Android phones)

As mentioned above, I use an Odroid C2 which has the same quad A53  as the Pi3, but clocked a little faster (1.5 GHz), with 2 GB RAM instead of 1 GB, with gigE instead of 100, and with eMMC and much faster SD card interface too. It has 64 bit Linux available and has had for a year I guess (i.e. since it came out). It's very nice. It's also only $5 more than the Pi3.

I also run 32 bit programs on it. I find that the same program often runs 15% faster compiled for Aarch64 than for Thumb2 (and Thumb2 is often faster than A32, due I guess to more program fitting into L1 cache).

[julianhigginson]

Have you ever even used a flavor of embedded linux? Your post makes me think not. Why would you set it up over and over? I set up my raspberry pi as a general purpose web and FTP server with temperature monitoring and an RTL SDR dongle several years ago and it's just worked ever since.

awww, bless.

I don't read this thread for a few days, and all the magic happens.

Anyway, yeah. I'm talking about proper custom designed products here, for mass production. About needing to have something that doesn't just "work OK for me" on my bench, but something that as well as possible is designed to not fail under any reasonable circumstance, foreseen or unforeseen.

[nctnico]

Most people in this thread work with the same assumption about reliability et al but just aren't so negative about using Linux.

[julianhigginson]

I'm not negative about it. I can and do use it. (Most days if you count VMs in my PC)

All I'm saying is there *is* a downside and a cost in time to using linux in a repeatable and reliable and properly updated way, and if you don't want to try and understand and manage that then you are going to fall into a big hole eventually...

My experience with VMs isn't too bad any more, because I just make sure I only have one purpose/job for one VM then I have way less dependency incompatibilities than when I tried just adding everything I ever needed to one install...

And for embedded projects I'm actually optimistic about containers as a way to mitigate package dependency clashes at a small cost of a bit of efficiency and object size. Though haven't had a reason to try them out in embedded linux yet so I'm not sure how it'll go...

But you know what? I chuck everything I need in my windows install and it keeps on chugging along (though to be fair, a few years ago I got to the point where I had done too many compiler installs/uninstalls and win7 PATH variable ended up bigger than 1000 (or was it 1024?) characters.. which somehow in some piece of windows guts, got truncated to 0... and everything that relied on having something in PATH stopped working... that was a bad day)