OS für Ultrascale

Das sind ARM-CPUs, oder?

Da gibt es ein https://en.wikipedia.org/wiki/Arch_Linux_ARM

Geht das vielleicht da drauf?

Dergute W. schrieb:

> OK, hab' mal geguckt, das mit RPU und APU scheint mir ja reines
> Marketingblubber von Xilinx zu sein. Das sind halt ARM-Prozessoren.
> Punkt.

Du bist ein Depp - Ausrufezeichen !

Bei ARM gibt es Cortex. und bei Cortex gibt es A R und M. Cortex-R ist 
für (harte) Echtzeit-und sicherheitskritische Anwendungen gedacht. Etwas 
was man mit Cortex-A eher nicht realisieren kann. Wer mal ein bißchen 
mit RasPi in Richtung embedded Echtzeit eignung probiert hat weiss das.

https://en.wikipedia.org/wiki/ARM_Cortex-R
https://de.wikipedia.org/wiki/ARM_Cortex-A
Beitrag "Raspberry Pi - Echtzeitsystem?"

Tobias B. schrieb:
> Ich wuerde aber auch erstmal zum Petalinux raten.
Dazu würde ich wiederum nicht raten. Ein Kollege hier kotz damit schon 
seit Wochen rum und bekommt es kaum ans Laufen. Grund ist die mangelnde 
Dokumenation von Xilinx.

S. R. schrieb:
> Letzterer ist für Linux ungeeignet, da keine MMU.
Braucht man die unbedingt für harte Echtzeit?

So wird's gemacht schrieb:
> Cortex-R ist
> für (harte) Echtzeit-und sicherheitskritische Anwendungen gedacht. Etwas
> was man mit Cortex-A eher nicht realisieren kann.
Da möchte ich gerne nachfragen:

Wenn die A (A53) nicht primär für harte Echtzeit geeignet sind (warum 
nicht?), wie passt das dann mit der Aussage der PLC2-Webseite zusammen:

"Die Realtime Processing Unit RPU bietet zudem optimale harte 
Echtzeitverarbeitung bei geringer Verlustleistung, ebenfalls mit 
flexibler Peripherieanbindung wie auch zur programmierbaren Logik."

Welches System / welcher Teil ist denn nun der für Echtzeit besser 
geeignete und warum?

Und dann noch das:

Zitat von der PLC2-Seite:

"Mit Hypervisor Technologie in der APU können auch zeitleich mehrere 
Betriebssysteme parallel betrieben laufen,oder auch protected CPU 
Systeme konfiguriert werden, für eine leistungsfähige Software 
Verarbeitung."

Mal abgesehen von dem schlimmen Deutsch verstehe ich das inhaltlich 
nicht!

Wie(so) werden mehrere OS gestartet?

Wie werden "protected" System gestartet (ich nehme an, die wirken 
isoliert von den anderen) und wieso soll das effektiver sein?

Man benutzt doch MultiCore um effektiv zu werden.

Elbi schrieb:
> Wenn die A (A53) nicht primär für harte Echtzeit geeignet sind (warum
> nicht?),

Beim RasPi sinds einfach Erfahrungswerte, da schwanken die 
Response-zeiten wie ein besutrunkener Seemann bei schwerer See.
Wenn man sich die Architekturunterschiede wie oben verlinkt anschaut, 
dann könnte hierfür "Deterministic interrupt handling as well as fast 
non-maskable interrupts" das Geheimnis sein warum der -R besser für 
harte Echtzeit geeignet ist als der -A mit seinen "nested IRQ".
Die getrennten Memory maps sind wohl vorrangig für sicherheitsrelevante 
Apps gedacht, können aber auch für Echtzeit gut sein, weil die Traps 
nach Speicherverletzungen entfallen. In die selbe Kerbe schlägt 
"Increased exception handling in hardware", auch ein -R feature. Beim -A 
wird halt viel vom OS abgehandelt, was der -R flott per HW abfrühstückt. 
Intressant auch die Möglichkeit Cache nicht zu benutzen um 
vorhersehbare und Kontextunabhängige Speicherzugriffszeiten zu 
garantieren 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0338g/Chdhbjjb.html

Elbi schrieb:
> "Mit Hypervisor Technologie in der APU können auch zeitleich mehrere
> Betriebssysteme parallel betrieben laufen,oder auch protected CPU
> Systeme konfiguriert werden, für eine leistungsfähige Software
> Verarbeitung."
>
> Mal abgesehen von dem schlimmen Deutsch verstehe ich das inhaltlich
> nicht!

Der Inhalt steckt in dem nicht zitierten folgenden Satz:
"Auch Safety und Secure Anforderungen werden nach Sicherheitstandards 
unterstützt."

Mehrerer OS/parallel arbeitende geschützte CPU starten macht unter dem 
Aspekt von Redundanz und Überwachung Sinn. Der -R wird eben für 
Sicherheitsanwendungen (Medizintechnik) vermarktet. Und da braucht man 
zuweilen CPU's die am selben Problem arbeiten und deren Output uberwacht 
wird. Ist dieser nicht mehr gleich, ist irgendwas nicht mehr 
deterministisch und das Gerät schaltet in den FallBack. 
https://history.nasa.gov/computers/Ch4-4.html

Elbi schrieb:
> Dazu würde ich wiederum nicht raten. Ein Kollege hier kotz damit schon
> seit Wochen rum und bekommt es kaum ans Laufen. Grund ist die mangelnde
> Dokumenation von Xilinx.

Was für Probleme kann man haben das PetaLinux auf den Ultrascale+ zu 
bekommen?
Für mich nicht ganz nachvollziehbar.
Sowohl YOCTO als auch PetaLinux draufzubekommen ist doch nicht wirklich 
kompliziert. Oder macht ihr da schon was ganz besonders kompliziertes? 
Was man halt schon hat, bei so einem Chip muss man für alles halt mal 
mit einer Woche statt mit drei-vier Stunden wie bei einem Cortex-M 
rechnen. Dessen sollte man sich bewußt sein ... vor allem sollten sich 
die Führungskräfte dessen bewußt sein. Man vergleiche nur die MALI, 
A-53, SMMU, USB Erratas mit dem eines Cortex-M.

Für die "kleinen" Module kommen ja die kurzen Erratas dann ja noch oben 
drauf. Ich war hier am anfang ein Gegner des ZYNQ Ultrascale+. 
Inzwischen hat das zu ist ganz interessant gewechselt und vielleicht 
heiße ich irgendwann sogar die Entscheidung gut.

Für die RPU natürlich FreeRTOS, µC-OS2 (beide für Port ein Morgenblock 
4h), embOS (gibts bestimmt auch für R5), ...

Insbesondere ein Port von Cortex-M7 zu R5 sollte ja pillepalle sein. 
Insgesamt ist der R5 inkl. MPU von seiner Architektur noch sehr 
überschaubar und der Port kein größeres Thema.

Auf dem A53 inkl. MMU finde ich das doch etwas komplizierter aber ist 
auch noch handelbar. Dort kann man ja auch für komplexe bedingte 
Kalkulationen einen Kern dem Linux entziehen. Die Frage ist da nur ob 
man für die Aufgabe dann wirklich ein OS braucht, aber für die 
Kommunikationsschicht ist es meist noch ganz nett.