Linux on ARM Automotive Infotainment SoCs?


Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,629
So I started down a web rabbit hole of looking at ARM SoC platforms that use updated versions of the PowerVR GPU in the Pyra. Yes, lots of unobtainable Apple stuff makes that list. However, I then started stumbling into automotive SoC platforms.

I had never heard of Renesas before, but they have built a rather wicked SoC platform.
http://linuxgizmos.com/renesas-goes-64-bit-for-latest-automotive-r-car-soc/

TI may have left the mobile phone/tablet markets, but they're still going strong in automotive.
http://linuxgizmos.com/ti-spices-up-jacinto-auto-socs-with-adas-support/

Which brought me to those articles and an interesting side discovery. Both list Linux as their primary supported OS. The above examples won't be shipping in large quantities for about a year and would both likely have power and thermal needs outside of the envelope for a handheld. But - they're still pretty wicked Linux compatible SoCs with some of the latest GPU technology around.

Assuming they get picked up by one or more automotive manufacturers, they should get produced in substantial quantities. In 5 years we'll all be searching through junk yards to salvage out the CPU boards from in-car infotainment systems to use as bench-top computers.
[doublepost=1491345990,1491343009][/doublepost]Adding in a link to the spec sheet for the Renesas H3.

https://www.renesas.com/en-us/solutions/automotive/products/rcar-h3.html
21mm X 21mm BGA with 1384 pins... I wonder if it could fit a Pyra SoC board's dimensions... It would probably need to be throttled a lot to fit the thermal envelope... LPDDR4... Insane number of interfaces, many of which could be ditched... Save that for 2-3 years from now...?

For reference, the OMAP5432 is a 17mm X 17mm BGA with 754 pins. A bit smaller.
[doublepost=1491347173][/doublepost]Interesting... There is the H3 linked above then there is the M3. From what I can tell they're essentially the same architecture but the M3 has only two A57 cores instead of the four found on the H3.

https://www.renesas.com/en-us/solutions/automotive/products/rcar-m3.html

And... Renesas makes dev boards for them. Pretty nice ones from the looks of it. And they're sold by distributors too - cool.
https://www.renesas.com/en-us/solutions/automotive/adas/solution-kits/r-car-starter-kit.html

The H3 dev board is not available yet and slated to cost $860 - yikes.

However, I am sorely tempted to purchase an M3 dev board. There are 22 in stock and they're $311.25...
https://www.digikey.com/products/en?keywords=RTP0RC7796SKBX0010SA09

Published 'How to boot Linux'...
http://elinux.org/R-Car/Boards/M3SK

Yocto?? Debian...
http://elinux.org/R-Car/Boards/Yocto-Gen3#Debian.2FUbuntu

Looking for cooler heads to prevail and tell me that there is nothing I could do with a $311.25 Renesas M3 dev board and how it would not be any fun and would only lead to disappointment because of this that and another, etc...

But, it has been a fun rabbit hole to run down.
 
Well, the biggest problem with automotive SoCs is that they're quite power hungry, as they aren't optimized. The size of them already tells you basically... they're often made 27nm or even bigger.
 
Well, the biggest problem with automotive SoCs is that they're quite power hungry, as they aren't optimized. The size of them already tells you basically... they're often made 27nm or even bigger.

Yes, they can be power hungry when maxing out those 10 CPU cores and all of the connected device capabilities. But - nothing says a device would have to keep all 10 cores available. The H3 above is a 21mm by 21mm BGA done on a 16nm process. It appears to have all of the accessories that a Pyra successor would need - even LPDDR4 and serious GPU capabilities - and then some/lots/insane.

In my perfect hypothetical world, Renesas (or other automotive SoC company) would be binning SoCs. Anything that fails due to factors a project like yours doesn't care about would, hypothetically, be a waste material for Renesas (or other automotive SoC company) and have value to a project like yours - which would not compete with their market.

IMHO, the real switch to making these automotive SoCs interesting is how far they have pushed the GPU engines on them. Automotive SoCs used to be headless or nearly so. That H3 can run 4 displays. Combine that with purported Linux support - it gets more interesting. Apparently Automotive Embedded Linux is a real thing now.

I'm not saying this should be jumped to and evaluated in detail today or even this year. But - in a year or two when you, hopefully, start looking into ARM SoC options for a Pyra SoC board re-do, give these types of SoC a good looking over. They have advanced considerably over the last couple of years.
 
I actually just got a renesas automotive board of some kind at the office. Literally just arrived today, I don't even know what CPU is on it; marketing guy just handed me a box and said I have 4 weeks to figure it out. Once I figure out what I'm dealing with I can let you know all about it (within NDA)
 
I actually just got a renesas automotive board of some kind at the office. Literally just arrived today, I don't even know what CPU is on it; marketing guy just handed me a box and said I have 4 weeks to figure it out. Once I figure out what I'm dealing with I can let you know all about it (within NDA)
WOOHOO!

Within NDA of course.
 
This does seem like it could have better perf and perf/W than OMAP5. If they have a good circuit implementation (unlike say, Qualcomm's A57s) and at least bothered a little with power saving modes.

Just so you know, thatdual-R7 isn't in there to get more performance out of the system. The R-series of CPUs have a bunch of safety features like ECC protection and various other error checking, and the two cores are run strictly in lockstop so that they appear as one core. The only purpose this serves is if the two CPUs end up with a different state it'll signal a fault happened and prompt some kind of safe recovery. This is the sort of thing automotive systems may want to run actual critical realtime car feedback systems in. For a handheld it'd probably not be very useful.
 
This does seem like it could have better perf and perf/W than OMAP5. If they have a good circuit implementation (unlike say, Qualcomm's A57s) and at least bothered a little with power saving modes.

Just so you know, thatdual-R7 isn't in there to get more performance out of the system. The R-series of CPUs have a bunch of safety features like ECC protection and various other error checking, and the two cores are run strictly in lockstop so that they appear as one core. The only purpose this serves is if the two CPUs end up with a different state it'll signal a fault happened and prompt some kind of safe recovery. This is the sort of thing automotive systems may want to run actual critical realtime car feedback systems in. For a handheld it'd probably not be very useful.

In my hypothetical, theoretical, perfect world, assuming that the producer is binning SoCs, they would theoretically have some coming off the line where the R-series and/or a few of the other cores have errata such that the result is unable to be used for their designed purpose. In this dream world, those could be obtained by a non-competing project like this one where the rest of the cores that we're not interested in can simply be disabled.

In the case of that H3 or M3 SoC, all we would really want/need are two of the fast cores, the GPU and memory/peripheral management. The other 6-8 cores could be unusable without impacting. What would otherwise be a disposal issue for the producer would have then have value. For us, the unused parts of the SoC would effectively be just more heat sink/spreader mass. For the producer, they make a bit of money off of something that would otherwise be landfill -and- gain an open source community that might find optimizations for their eLinux implementation, potentially saving them money.

Of course this is all hypothetical and this project is a long ways out from being able to start evaluating SoC options for it's next generation. I'm simply bringing this up as another option to consider when that time comes. These automotive SoCs have become very powerful recently. The number of players in the mobile/handheld ARM space that do Linux at all or well seem to be dwindling. But here is an example of an automotive SoC with a public git and directions on how to install Debian onto their platform and mention availability to enthusiasts for their dev board. It checks a lot of the requirement boxes, but it comes from a direction/source/industry that I would not have previously considered as an option before I stumbled on it by chasing down implementations of newer PVR versions on ARM.
 
In my hypothetical, theoretical, perfect world, assuming that the producer is binning SoCs, they would theoretically have some coming off the line where the R-series and/or a few of the other cores have errata such that the result is unable to be used for their designed purpose. In this dream world, those could be obtained by a non-competing project like this one where the rest of the cores that we're not interested in can simply be disabled.
In the real world, I suspect these days they just have a test rig that exercises all of the components and tests them all. It is doesn't pass they all go into a single bin. To actually identify which bits have holes in them would require extra testing, which probably isn't actually worth doing, I've no real idea what the failure rates on these parts are these days - they don't tend to release that info while things are still on sale, but I propose it's not high enough to spend the extra money on testing what works and how fast, and if they did they'd already have a different line of parts announced that is made up of slow/broken faster chips and dedicated production of slower chips - can you find that part?
 
In the real world, I suspect these days they just have a test rig that exercises all of the components and tests them all. It is doesn't pass they all go into a single bin. To actually identify which bits have holes in them would require extra testing, which probably isn't actually worth doing, I've no real idea what the failure rates on these parts are these days - they don't tend to release that info while things are still on sale, but I propose it's not high enough to spend the extra money on testing what works and how fast, and if they did they'd already have a different line of parts announced that is made up of slow/broken faster chips and dedicated production of slower chips - can you find that part?

Not really worth that exercise at this point because the project isn't there yet.

My original intent in this wasn't, "We need to use this SoC," but rather, "Someday when it is appropriate to go looking for the next SoC and run into the same headache of mobile SoC producers not wanting to give the time of day to the project, give some consideration to the automotive SoC world as they're now producing some pretty cool ARM stuff with Linux support." I have no idea if they would be any more interested in supplying small enthusiast projects with SoCs, BUT they do reference enthusiasts in the eLinux support pages and description pages for their dev boards. The fact that this company is willing to sell their dev boards to the non-automotive world might be a positive indicator too. We'll have to see where things are at in a year or two.

I'm still anxiously awaiting any news from @WizardStan, though whatever he received may have nothing to do with this thread. Renesas makes a lot of stuff.
 
I'm still anxiously awaiting any news from @WizardStan, though whatever he received may have nothing to do with this thread. Renesas makes a lot of stuff.
I need to reach out to Renasas, can't figure out how to connect the bloody thing to a network so I can poke around at it.
Unfortunately my marketing manager's father in law passed away this morning so I wasn't able to ask him for the contact I needed. Might be a few days.
 
I need to reach out to Renasas, can't figure out how to connect the bloody thing to a network so I can poke around at it.
Unfortunately my marketing manager's father in law passed away this morning so I wasn't able to ask him for the contact I needed. Might be a few days.
Network or do you need to start at the serial debug port?
 
Finally figured it out. Not sure why exactly, but minicom doesn't like talking to it. screen does though, so that was my workaround.
It's based on the Renesas R-CAR E2 board, an older model with a dual core A7 @1Ghz and 1GB RAM.
Unfortunately it's running some kind of custom version of linux that doesn't have all the drivers, notably the video, and I don't have time to try and find/build them, so I'm not sure what I can test for you here.
 
Finally figured it out. Not sure why exactly, but minicom doesn't like talking to it. screen does though, so that was my workaround.
It's based on the Renesas R-CAR E2 board, an older model with a dual core A7 @1Ghz and 1GB RAM.
Unfortunately it's running some kind of custom version of linux that doesn't have all the drivers, notably the video, and I don't have time to try and find/build them, so I'm not sure what I can test for you here.

Sounds like they gave you an older generation board. I was in hopes that you would have received an H3 or M3 developer system.

The old platforms don't have much for on-board video hardware anyway
 
well, this should be good for connectivity with other linux devices in the future, i hope?
 
Almost certainly something in the Freescale i.MX6 line I'd wager; that's been my experience so far, almost everything is Freescale; they've got the best automotive grade CPUs. I remember TI was trying to enhance their automotive lineup but nothing that's crossed my desk has had anything by them in it.
 
Back
Top