Onderwerp: Nieuwe kernel serie RPI Raspian

brambo schreef :

Probleem met draadloze accesploint opgelost in deze versie ?

Beste S,

probleem met draadloze Access Punt ? Niet bekend met een probleem. Draait hier feilloos "headless" met een VNC client op een Chromebook.

Alleen tegelijk met Wifi naar buiten is met de nieuwe RPI3B+ wat lastiger. Gewoon een passende Wifi dongle erbij en je hebt ze allebei tegelijk.

Groet,

Bram

brambo schreef :

je hebt het zelf geschreven.
in de vorige kernel zat dit probleem

Die was toch al even geleden opgelost?
Uit draadje "starten met PI 3+ en openplotter. --> Wifi" van 01 apr 2019 09:33
brambo schreef :

De laatste update van Raspian bevat nu ook de kernel 4.19.42.

Werkt zeer goed en snel in combinatie met VC4 OpenGL driver.

Het gaat hier om de interne werking van Raspian Linux. Zou niet weten waarom dit op een aan de DSI poort aangesloten systeem niet zou werken.

Of is zo'n scherm wat traag ?

Met een headless gebruik (zonder aangesloten scherm) en bediening via een ander systeem met VNC client, Apple of Chromebook bijvoorbeeld, is er een ander probleempje.

Systeem kijkt steeds wat voor monitor scherm er aangesloten is. Als er dan bij headless toepassing geen aangesloten monitor wordt gevonden, dan valt deze terug tot een lage resolutie. Dat is vervelend als je een VNC client gebruikt met de mogelijkheid van een hoge resolutie.

De oplossing hiervoor is een Dummy HDMI dongle te gebruiken. Die geeft systeem de indruk dat er wel een monitor is aangesloten.

Dingen kosten minder dan € 8,-. Zijn speciaal gemaakt voor headless (zonder monitor) toepassingen.

Hier een voorbeeld van zo'n dongle:

www.amazon.com/CompuLab-fit-He...ulator/dp/B00FLZXGJ6

Je hoge resolutie VNC client werkt dan perfect.

Groet,

Bram

brambo schreef :
Dat weet ik ook niet, maar het is wel een feit. En het is ook de reden dat de "fake KMS driver" überhaupt bestaat.

brambo schreef :
je kan gewoon de resolutie vast zetten onder Preferences/Raspberry Pi Configuration/ System/ Resolution/ Set Resolution
zie "toegang-met-vnc-viewer"

Maar het kan ook gewoon met sudo Raspi-config / 7 advanced options / A5 Resolution

brambo schreef :
Beste Bram,
Heb je intussen al eens getest wat de voordelen zijn van een 64-bits systeem met een Pi4?
Biedt dit prestatievoordelen?

De reden achter de vraag is eenvoudig:
- informatie over OpenCPN voor ARM64 is slecht te vinden en compileren vanaf git is niet plug & play.
- een OpenCPN en XyGrib repository bestaan nog steeds alleen voor ARMHF (32-bit), zyGrib is wel te vinden(!).
- bij andere ARM-oplossingen dan de Pi4 ligt overschakelen op 64-bit meer voor de hand dan te starten van 32-bit (als OpenCPN beschikbaar is).

Ik zie nog niet aankomen dat OpenPlotter binnenkort overschakelt op ARM64. Het lijkt mij dat het grote publiek nog met de Pi2 en Pi3 aan het spelen is, tot die hardware versleten is.

PS Mochten er mensen geinteresseerd zijn in OpenCPN en XyGrib voor ARM64 dan kan ik wel ergens tijdelijk enkele deb's voor Ubuntu 18.04 ARM64 neerzetten om te testen, te weten een complete set voor OpenCPN_5.0 en XyGrib_1.2.7, inclusief (o.a.) objsearch, ocpn-draw en weatherrouting.

Groeten,
Huub

Beste Huub,

als ik regelmatig de kernel opwaardeer met rpi-update, dan zie ik daar ook tussen staan een kernel aangeduid met V8. Dat is volgens mij een 64 bits kernel. Als dan kijk wat mijn opgewaardeerde systeem aangeeft met uname -r dan is dat de V7 versie.

Kennelijk moet je 64 bits kernel kunnen aanzetten.

Maar goed de RPI met de laatste updates werkt zo goed dat ik er verder niet naar heb gekeken.

Zou op zich geen probleem hoeven zijn, want 32 bits software kan ook prima werken in een 64 bits omgeving.

Nieuwe dingen zijn zeker interessant om te proberen.

Groet,

Bram

brambo schreef : Dat zou op zich verklaren waarom veel mensen met een 64-bit systeem werken zonder 64-bit OpenCPN.

Een 64-bits kernel "aanzetten" betekent natuurlijk je hele distributie vervangen. Dat je dan nog 32-bits software naar binnen hengelt is een optie, maar de open source methode is natuurlijk hercompileren.

Een 32-bit OpenCPN in een compatibiliteitsmode laten werken was niet bij mij opgekomen.
Iets met quick en vooral dirty...

@brambo
Als jij een RPI4 met ARM64 zou gebruiken, welke distributie zou jij dan aanraden?

Voor de USB-lock (oesENC) wil men de sglock library porten naar ARM64.
De vraag is concreet "op welke target distributies moeten we ons richten"?

Dus de vraag "en kun je het dan testen" zal hopelijk snel volgen.

Beste Reuver,

ik heb al eens gekeken naar een 64 bits systeem voor mijn RPI4.

Die vraag is uiteraard ook al eens eerder gesteld aan de Raspian mensen. Volgens hen is er geen enkel voordeel te behalen, eerder andersom:

Benefits of 64 bit:

The two primary benefits of using a 64 bit processor/operating system is that the device can handle more than 4 GB of RAM, and natively handle integers larger than 2^32 without the need for a bignum library.

The Raspberry Pi doesn't have more than 4 GB of RAM. At a 1 GB of RAM, you've completely lost the first of the two primary benefits. As for the second benefit, what percentage of people are actually using enough giant numbers that it makes sense for the foundation to support a whole second operating system? As is, the RPi can use huge numbers through software methods, but it seems like if you're going to be consistently in that realm, you need to be using better hardware anyway.

Problems with 64 bit:

The ability to store a larger number isn't granted by magic. Rather, the size of memory objects needs to be increased. In C (and C++) this means changing an int to int64_t. This isn't done automatically, hence the comments about the foundation not wanting to maintain two branches.

Additionally, many applications simply don't provide a benefit (for most users) when run in 64 bit mode. Notice that most web browsers, MS Office, and a whole host of other popular software is all still shipped and maintained in a 32 bit manner. Sure you can get your hands on an 64 bit release of MS Office, but it's rarely used.

If the application/operating system is written to take advantage of a 64 bit architecture, your application is going to use more memory, simply because variables and pointers are taking up more space. Usually this is a relatively small trade off for machines that will benefit from the perks. In our case, we have very few perks, and very little RAM.

Also of note:

Just because you're running on a 64 bit machine, doesn't mean the application isn't running as 32 bit. Windows makes this very clear by having two different install paths, C:\Program Files and C:\Program Files (x86).

So, will the foundation likely provide 64 bit support?:

We're back at the same point of, "Some people may see benefit, but most will not.". You'll certainly see other projects offering 64 bit builds, but unless the foundation gets a lot of undeserved (imo) flack, they probably won't and shouldn't (imo). Creating and maintaining a separate 64 bit branch isn't a s

Er schijnt wel een raspian 64 versie te zijn. Zal ongetwijfeld gebaseerd zijn op Debian Buster.

Interessant zijn ook de ontwikkeling door Raspex. Die steeds de laatste software toepast. Misschien ook eens op deze website kijken.

Echter 64 bits is wel de toekomst. Nog even gekeken op de website van Codejs voor een ander 32 bits systeem.

32 bits is er nog wel voor Windows, maar al niet meer voor Linux.

De v8 kernel schijnt wel voor 64 bits systemen te zijn.

Groet,


Bram

brambo schreef : De argumenten zijn correct voor de RPI3.
De RPI2 en RPI3 zijn net als bijna alle zuivere A53 CPU oplossingen minder geschikt voor 64-bit omdat het geheugen bij de meeste bordjes beperkt is tot ca. 2GB. Bij overschakeling op 64-bit heb je dan wel de lasten en niet de lusten.
De meeste ontwikkeling voor arm vindt plaats voor telefoons en embedded hardware als tv's. Dat is allemaal 64-bit. Drivers vinden voor 32-bit wordt steeds lastiger.

Volgens mij werk jij ongeveer net zolang met Linux als ik. Dan weet je hoe belangrijk beschikbaarheid van drivers is.

Maar goed, ik kan me voorstellen dat je geen voordelen ziet in 64-bit voor de RPI4.

Beste Reuver,

er zijn inderdaad niet veel voordelen aan 64 bits voor RPI software. Echter het is de toekomst, zoals je al aangaf. Daarom ga ik het zeker proberen.

Raspex is meestal snel om nieuwe toepassingen samen te stellen.

Wil eerst even kijken of direct invoer van SignalK ook op de RPI Opencpn mogelijk wordt.

Er is altijd wel weer wat nieuws te ontdekken.

Groet,

Bram

brambo schreef :
Zelfde code base, dus zou moeten werken.

Bij OpenCPN op de ARM64 zie ik naast TCP, UDP en GPSD ook de optie voor Signal K.
Probleem hier is dat mijn Signal K server nog niet ingericht is.

Ik ga er vanuit dat je met de laatste versie van ARMHF hetzelfde ziet.

Ik kan wel een ARM64 build maken vanaf GitHub, maar de ARM32 image die ik had vond ik niet goed genoeg voor compilatie. Dus ik kan je helaas geen ARMHF-versie leveren.

Beste Reuver,

SignalK in een 64 bits systeem kun je het handigste installeren met ??? OpenPlotter.

Daar staan ook voor andere Linux versies handige hulpmiddelen in, plus het installeren van de SignalK server.

Serieele instelling zijn ook aan te bevelen. Die kun je een alias geven zodat ze altijd gezien worden ongeacht de usb poort.

Je kunt het net als OpenCPN doen met ppa.

sudo add-apt-repository ppa:openplotter/openplotter

(als dat commando niet aanwezig is dan het volgende eerst installeren:
sudo apt install software-properties-common)

Je krijgt dan bij ppa ook de melding dat de key ontbreekt. Key kopieren.

Die kun je eenvoudig aanmelden met:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys (hier de ontbrekende key)

Helaas werkt het installeren van SignalK niet op mijn 32 bits Buster versie. Ligt aan een versie van Nodejs.

Update en dan zie je in Synaptic de OpenPlotter opties gereed staan om te installeren.

SignalK werkt prima op mijn amd64 Linux Mint Tricia. Daarna kun je ook de OpenCPN beta installeren met de SignalK invoer.

Groet,

Bram

Nog een laatste bericht:

De SignalK server werkt nu ook op mijn 32 bits Buster systeem (EEPC). Installatie uitgevoerd met Openplotter.

Er treedt dan echter een probleem op. Als je dan kijkt naar de NodeJS versie dan is dat 1O.

In de servers instellingen hier een 8 van gemaakt maken in plaats van 10.
Updaten.

Er komen dan een hele rij bestanden voorbij met als resultaat een werkende SignalK server.

Werkt hier nu op de RPI4 en 3, Linux Mint Tricia 64 bits en Sparky Buster 32 bits op de EEepc.

Bram

brambo schreef :
Ik ben altijd voor "liever slecht gejat dan goed verzonnen" maar in dit geval heeft het gebruik van externe packages toch weinig voordelen.

Odroid en Raspberry hebben wel een vergelijkbare I2C bus, maar de verschillen zijn groot. Ik moet dit volgende week eens op m'n gemak proberen, stap voor stap.

Beste Reuver,

ik doe dit ook stap voor stap. Ik heb nu wel de laatste stap gezet. De SignalK server draait nu op drie verschillende systemen.

Eenvoudig de serieele settings met een alias voor herkenning op de USB bus/hub en de GPS muis aansluiting in SignalK.

OpenCPN ontvangt de data met tcp localhost poort 10110. Directe invoer van SignalK is overigens poort 8375.

Wacht nu op mijn NMEA2000 GPS om ook op de 3 systemen de canbus instelling te laten werken. Dan is hiermee ook NMEA2000 invoer en uitvoer mogelijk.

De boot staat in de stalling en ik heb daar geen ontvangst, dus moet ik het thuis proberen.

Als NMEA2000 is aangesloten dan zal ik daarvan verslag uitbrengen.

Groet,

Bram

brambo schreef :

Beste Reuver,

Nu vanavond (laat) ook de Raspberry 4 geprobeerd met een 64 bits systeem. En moet aangeven dat dit toch wel wat beter en sneller werkt dan de 32 bits.

Inmiddels draait OpenCPN er ook op. En de SignalK server.

Alles geinstalleerd met de opties van Openplotter voor Linux.

Ook mijn GPSmuis werkt via SignalK.

Kernel versie is inderdaad 64 bits V8. (kernel versie 4.19.88-V8+)

Groet,

Bram

Moet het nog wel wat verder proberen.

Misschien beter een nieuw draadje te starten met experimenteel 64 bits systeem op een Raspberry Pi 4.

Nieuws over dit oude draadje. Dit is een bericht voor de fervente updaters onder jullie.

De 4.19 kernel versie is nu verlaten en men is experimenteel overgegaan naar kernel 5.4 en navolging van andere Linux systemen.

De versie die nu verschijnt is: 5.4.35. V7 is voor de 32 bits systemen en V8 voor de 64 bits.

Ook de SignalK server is nu versie 1.29. En de MXTommy KIP versie is al eerder opgewaardeerd.

Ik kan berichten dat het na de kernel update prima werkt. Systeem is opnieuw sneller geworden.

Met permissie wacht ik op versie 5.4.36.

Brambo, dat was een grapje.

roozeboos schreef :
Ik verbaas mij erover. Je krijgt steeds meer belangstelling voor dit krakkemikkige, goedkope, en krachtige energie-zuinige "hobby" ding.

Voor de goede orde, ik ben niet meer de enige gebruiker van SignalK in Nederland er zijn er inmiddels wel meer.

Als ik er eens wat over schrijf is er altijd een van de eerste die het leest.

Dit is geen grapje.

Groet,

Bram