Tervehdys,
Olen yrittänyt saada 8th:ta täysin toimimaan MYiR MYD-LD25X raudalla OpenSTLinux:in päällä. Kyseessä on siis ST:n STM32MP257D MPU pohjautuva tuote.
Ikävä kyllä MYiR ei ole itselleni tutumpaa Debian käyttöjärjestelmä imagea vielä julkaissut ja beta image jonka minulle lähettivät ei tue rautapuolen kiihdytyksiä. Muuten pidän tuotteesta Raspberry Pi:tä enemmän, koska on pieni kulutuksinen eikä käytännössä lämpene käytössä juuri ollenkaan.
Ongelmani on sellainen, että 8th toimii OpenSTLinux:in päällä kivasti, mukaan lukien SDL3 backendiä käyttävä Nuklear GUI käyttäen Wayland ja KMSDRM ajureita. Ongelmana on, että C-kirjastoa käyttävät osat 8th:ssa eivät toimi ja 8th vain kuoleee äänettömästi ilman virheilmoituksia.
Onko ideoita, mistä voisi johtua?
Esimerkiksi 'chdir' function toteutus näyttää tältä:
"libc.so.6" lib libc libc drop "ZZ" "getenv" func: getenv "VZ" "chdir" func: I:_chdir : chdir f:expand-home I:_chdir ;
Kokeilin myös, että 8th saa ladattua kirjaston:
"libc.so.6" lib libc libc .s
Ja sain toivotunlaisen tuloksen:
Stack depth: 1 0 X: 0000ffff832e6340 3 X:3:0000ffff832e6340:7:7:0000ffff83c11b10
Kuitenkin, mikäli yritän käyttää koodissa määriteltyä 'chdir' sanaa, 8th vain kuolee äänettömästi ilman virheilmoituksia.
Onko 8th:ssa erilaisia lokitustiloja? Saatko esimerkiksi jollain lipulla ulos tarkemman stack tracen kaatumistilanteessa?
Tuolla sanottiin, että OpenSTLinux tarjoaisi standardin kernel interfacen, joten tuskin libc-toteutus on sinänsä ongelma.
---
Yleisempi ongelma olisi tietysti, että olet vain asentanut libc:n väärin tai se ei toimi käyttöjärjestelmän versiossa, joka sinulla on.
Tai olet asentanut 8th:in väärin eli esim. jättänyt ruksimatta jotain tai passaamatta jotain flageja, jotka liittyvät esim. libc:n polkuihin. Oletko varma, että vaikka se osaa ladata kirjaston, niin se löytää symbolit?
mavavilj kirjoitti:
Yleisempi ongelma olisi tietysti, että olet vain asentanut libc:n väärin tai se ei toimi käyttöjärjestelmän versiossa, joka sinulla on.
Tai olet asentanut 8th:in väärin eli esim. jättänyt ruksimatta jotain tai passaamatta jotain flageja, jotka liittyvät esim. libc:n polkuihin. Oletko varma, että vaikka se osaa ladata kirjaston, niin se löytää symbolit?
Käytän valmistajan toimittamaa käyttöjärjestelmä imagea. Järjestelmä tuntuu muuten toimivan erittäin hyvin ja pidän epätodennäköisenä, että mikään muu järjestelmän komponentti ei käyttäsi hyödyksi C:n standardi kirjastoa.
Mikäli kirjaston saa ladattua, niin pitäisi kyllä toimia.
8th:ta ei voi asentaa väärin. Paketti pitää vain purkaa johonkin ja ajaa sen jälkeen asennuskripti, mikä purkaa mukana tulevat tietokannat oikeisiin paikkoihin.
groovyb kirjoitti:
Onko 8th:ssa erilaisia lokitustiloja? Saatko esimerkiksi jollain lipulla ulos tarkemman stack tracen kaatumistilanteessa?
Normaalitilanteissa saan yleensä kohtuullisen hyvät tiedot ohjelman kaatumisesta. Jännästi 8th toimii muuten ihan hyvin, mutta kun esimerkiksi koittaa omassa ohjelmassa vaihtaa työhakemistoa, mikä käyttää hommaan C:n standardikirjastoa, niin 8th kuolee hiljaisesti ilman virheilmoituksia.
Ajattelin ehdottaa stracea ja gdb:tä, mutta oletkin saanut jo samat neuvot: https://8th-dev.com/forum/index.php?topic=2982.15
Vähän outoa aloittaa keskustelu samasta aiheesta molemmissa paikoissa. Putkassa tuskin edes on muita kyseisen kaupallisen kielen käyttäjiä.
Merkinnät @ ja @@ selitetään nm:n manuaalissa.
jalski kirjoitti:
8th:ta ei voi asentaa väärin. Paketti pitää vain purkaa johonkin ja ajaa sen jälkeen asennuskripti, mikä purkaa mukana tulevat tietokannat oikeisiin paikkoihin.
Mistä tiedät, että ne paikat ovat STM32:n jossain OpenSTLinux-toteutuksessa samat kuin jollain desktop-Linuxilla?
Mistä tiedät, että 8th on hyvin tuettu ko. alustalla ja käyttöjärjestelmällä?
En tiedä STM32:sta, mutta esim. Android on huomattavan erilainen kuin desktop-Linux, joten Linuxilla toimiva koodi ei todellakaan toimi Android:illa ja Bionic:illa välttämättä. Se toimii, mikäli Bionic tarjoaa tarvittavat funktiot ja niiden headerit ovat samat kuin desktop-Linuxilla.
Sekin, että vaikka saisit ARM-Debianin sille, niin ei se tarkoita, että x86-Debianin ohjelmat tulee kääntymään sille tuosta vaan.
Yleensä toisen alustan "libc":lle ei voi olettaa kääntyvän muita kuin hyvin tarkasti tiettyä C-standardia mukailevia projekteja. Esimerkiksi CPython:ikaan ei käänny tuosta vaan. Sen sijaan, sulautettuihin järjestelmiin on kehitetty MicroPython:
Voi olla, että SDL:n joidenkin osien toiminta on ihan random-tsägää eikä SDL:kään ole tosiasiassa kovin hyvin tuettu.
Yleensä tuollaisilla alustoilla käytetään kai QEMU:a, jos tarvitsee saada hyvä yhteensopivuus muille alustoille.
Esim.:
"Zephyr was a nice introduction to show me the limitations of an embedded system. Another thing I learned is that I missed the POSIX commands, which I’m so used to under Linux."
"This brought me to qemu, which worked just fine as I will describe in this article. I will make qemu run an a STM32 with a Linux kernel and BusyBox which gives me most of the familiar linux commands and tinyutils to create a httpd / php / ssh."
jlaire kirjoitti:
Vähän outoa aloittaa keskustelu samasta aiheesta molemmissa paikoissa. Putkassa tuskin edes on muita kyseisen kaupallisen kielen käyttäjiä.
Täällä varmasti löytyy kuitenkin useampi Linux käyttäjä ja jokunen todennäköisesti myös käyttää ARM pohjaisia laitteita?
mavavilj kirjoitti:
Voi olla, että SDL:n joidenkin osien toiminta on ihan random-tsägää eikä SDL:kään ole tosiasiassa kovin hyvin tuettu.
Yleensä tuollaisilla alustoilla käytetään kai QEMU:a, jos tarvitsee saada hyvä yhteensopivuus muille alustoille.
SDL3 kyllä toimii ihan hyvin. QEMU:n kautta tuskin saa hardware tukea esimerkiksi GPU:lle, mikä pienitehoisen laitteen kanssa on aika iso juttu käytettävyyden kannalta.
jalski kirjoitti:
(28.03.2025 13:42:40): ”– –” SDL3 kyllä toimii ihan hyvin. QEMU:n kautta...
No sitten se voi olla, että OpenGL (tai OpenGL ES) tms. on paremmin tuettu kuin muut kernel funktiot.
En kuitenkaan löydä hakukoneella mitään selvää vinkkiä siitä, että SDL olisi hyvin tuettu STM32:lla. Edit: no tässä jotain: https://wiki.st.com/stm32mpu/wiki/
Tuo tuen painottuneisuus olisi loogista, koska olet luultavasti aika minoriteetti, joka yrittää saada STM32:lle edes jotain vaihtoehtoista ohjelmointikieltä. Yleensä noilla alustoilla voi korkeintaan olettaa, että jokin Lua saattaa tsägällä toimia. Muuten perusoletus on aina käyttää C:tä ja ehkä joiltain osin C++:aa.
mavavilj kirjoitti:
Tuo tuen painottuneisuus olisi loogista, koska olet luultavasti aika minoriteetti, joka yrittää saada STM32:lle edes jotain vaihtoehtoista ohjelmointikieltä. Yleensä noilla alustoilla voi korkeintaan olettaa, että jokin Lua saattaa tsägällä toimia. Muuten perusoletus on aina käyttää C:tä ja ehkä joiltain osin C++:aa.
Tämähän ei siis kuitenkaan ole mikään pelkkä mikrokontrolleri, vaan täysiverinen Linux tietokone ja pitäisi kyetä ajamaan ohjelmia ihan samalla tavalla kuin Raspberry Pi ja kumppanit.
jalski kirjoitti:
(28.03.2025 14:09:27): ”– –” Tämähän ei siis kuitenkaan ole mikään pelkkä...
Joo no sitten kannattaa varmaan tutkia, että pitäisikö 8th:in toimia muilla, jos se toimii RPi:llä. Esim. ESP32:lla tuo ei ole noin, vaan RPi:llä on usein enemmän tukea.
Se QEMU on nimenomaan tuohon, että jos se toimii RPi:llä, mutta ei toisella, niin se voi toimia silti QEMU:loimalla RPi OS:iä.
8th:in sivuilla ei näy mainintoja STM32:sta.
Linuxeissakin esim. Clear Linux ei ole todellakaan kovin samanlainen kuin vaikkapa Debian.
mavavilj kirjoitti:
(28.03.2025 14:13:20): ”– –” Joo no sitten kannattaa varmaan tutkia, että...
Suurin osa markkinoilla olevista ARM SBC laitteista on melko pitkälti Raspberry Pi yhteensopivia. MYD-LD25X kortilla on jopa Raspberry Pi:n 40 pinninen standardi GPIO header.
Ajan tällä hetkellä 8th:ta onnistuneesti vanhemmalla tehottomammalla STM32MP157 pohjaisella laitteella.
STM32MP257D pohjaisella MYD-LD25X kortillakin 8th toimii melkein kokonaan.
Linkitetyt kuvat huonoja, huonossa valossa puhelimella otettuja...
Tokihan nuo "chdir" yms. toimimattomuuksien pitäisi näkyä kaikissa muissakin ohjelmissa, jotka käyttää libc:tä? Tai jos ne eivät näy, niin silloin vika on aivan varmasti 8th:issa tai sen asennuksessa.
Sen sijaan, että ainoastaan esim. "chdir" oireilisi viittaisi jonkin sortin sotkuun käyttöoikeuksissa, kuten:
https://stackoverflow.com/a/42340636/29773838
tai
https://www.reddit.com/r/C_Programming/comments/
mavavilj kirjoitti:
Sen sijaan, että ainoastaan esim. "chdir" oireilisi viittaisi jonkin sortin sotkuun käyttöoikeuksissa, kuten:
https://stackoverflow.com/a/42340636/29773838
tai
https://www.reddit.com/r/C_Programming/comments/
rrdz16/chdir_wont_close_the_directory/
Käytän sarjakonsolia USB - TTL kaapelilla ja roottina, eli käyttöoikeusongelma on epätodennäköinen vaihtoehto.
jalski kirjoitti:
(28.03.2025 15:07:27): ”– –” Käytän sarjakonsolia USB - TTL kaapelilla ja...
No Linuxeissa on tullut vastaan se, että kaikkia asioita ei esim. ole tarkoitettu ajettavan rootina.
Tuossa on testi, jolla voit testata, että toimiiko chdir() oikein:
Jotain vinkkiä:
Oletko tarkistanut ohjelman paluuarvon (echo $?), saako siitä jotain vinkkiä? Antaisiko gdb tai valgrind lisätietoa ongelmasta?
Arch Linux ARMilla 8th:n testaus tyssäsi nyt jo siihen, että järjestelmässä on libffi.so.8 mutta 8th:lle pitäisi olla libffi.so.7.
En gdb:tä ole käyttänyt ja saa tuosta mitään irti:
Reading symbols from /opt/8th/bin/rpi64/8th... (No debugging symbols found in /opt/8th/bin/rpi64/8th) (gdb) run Starting program: /opt/8th/bin/rpi64/8th Program received signal SIGSEGV, Segmentation fault. 0x000000000043da8c in ?? () (gdb) backtrace #0 0x000000000043da8c in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
root@myd-ld25x:~# /opt/8th/bin/rpi64/8th root@myd-ld25x:~# echo $? 1 root@myd-ld25x:~#
Metabolix kirjoitti:
Arch Linux ARMilla 8th:n testaus tyssäsi nyt jo siihen, että järjestelmässä on libffi.so.8 mutta 8th:lle pitäisi olla libffi.so.7.
Perkule! Näyttäisi olevan minullakin asennettuna 'libffi.so.8'. Saatko Arch Linux:illa jonkun näköisen virheilmoituksen, vai kaatuuko suoraan? Tuo kyllä täsmäisi siihen, että kaatuu FFI:tä käytettäessä!
root@myd-ld25x:/usr/lib# ls libffi* libffi.so.8 libffi.so.8.1.2
Ei Segmentation Fault:ista voi oikein päätellä mitään. Jotakin muistialuetta yritettiin, mikä ei ollut olemassa tai johon ei ole pääsyä.
mavavilj kirjoitti:
Ei Segmentation Fault:ista voi oikein päätellä mitään. Jotakin muistialuetta yritettiin, mikä ei ollut olemassa tai johon ei ole pääsyä.
Melko varmasti syypää on kyllä tuo 'libffi.so.8', mikäli 8th vaatii 'libffi.so.7':n. Kiitokset, Metabolix!
Puuttuvasta kirjastosta tulee kyllä virheilmoitus, koska 8th ei edes käynnisty:
./bin/rpi32/8th: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
Kirjaston versio voi tietysti olla eri kuin sinulla, koska minulla on RPi2, 32-bittinen Linux ja 8th:n ilmaisversio, jonka juuri latasin. Voit tarkistaa komennolla ldd, mitä kirjastoja kyseinen binääri oikeasti vaatii.
Tuolla alussa kuitenkin jo näytit, että libc ilmeisesti saadaan jollain tavalla ladattua, kun siitä muodostuu jokin 8th:ssa käsiteltävä objekti. Eli olettaisin, että versionumerosta tai puuttuvasta kirjastosta ei ole kyse.
Normaalin kirjaston kohdalla laittaisin gdb:lla breakpointin kutsuttavaan funktioon, jolloin jos koodi pääsee edes siihen asti, voisi yrittää tutkia pinoa ja rekistereitä ja ymmärtää, mikä on mennyt pieleen. Normaalisti linkitettävän kirjaston kanssa voisi yleensä vain kirjoittaa gdb:ssä break chdir ennen sovelluksen käynnistystä. Nyt kun libc ladataan dynaamisesti, en äkkiseltään osaa sanoa, miten breakpoint saataisiin oikeaan kohtaan. Pitäisi varmaan ensin laittaa breakpoint siihen funktioon, jolla libffi lataa kirjaston, ja kun on varmistettu libc:n lataaminen, voisi yrittää sinne saada breakpointin. Lisäksi pitäisi tietysti osata ARMin käskykantaa ja kutsukäytäntöä sen verran, että pystyy breakpointin kohdalla tulkitsemaan, missä vika.
Segmentation fault virheenä sopii esim. siihen, että kutsu ohjautuu väärään paikkaan (jotain vikaa libc:n lataamisessa tai oikean symbolin haussa) tai että funktion parametrit tulkitaan väärin (jokin vika libc:n ja libffi:n ja 8th:n kutsukäytännöissä).
Metabolix kirjoitti:
Puuttuvasta kirjastosta tulee kyllä virheilmoitus, koska 8th ei edes käynnisty:
./bin/rpi32/8th: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
Viitsitkö kokeilla:
8th -ee '"Hello World!\n" .'
Antaako käynnistää väärällä kirjastolla? Mikäli suorittaa pelkän 8th:n binäärin, niin käynnistää REPL:n ja käyttää FFI toiminnallisuutta.
jalski kirjoitti:
Viitsitkö kokeilla:
8th -ee '"Hello World!\n" .'
Sama virhe tulee siitäkin. Nyt tarkistin, että ldd:n mukaan kyseessä ei ole dynaamisesti linkitetty binääri, eli 8th taitaa ladata kaikki ulkopuoliset kirjastot jollain omalla tavallaan, ja ilman lähdekoodia olen tietysti täysin arvailujen varassa.
Netissä väitetään, että libffi on myös CPythonissa käytössä, joten yksi mahdollisuus on ensin kokeilla, saako Pythonilla kutsuttua libc:n chdir-funktiota. Ainakin minulla seuraava Python-koodi tulostaa ensin suoritushakemiston sisällön ja sitten /-hakemiston sisällön.
import ctypes
libc = ctypes.CDLL("libc.so.6")
libc.system(b"ls\0")
libc.chdir(b"/\0")
libc.system(b"ls\0")EDIT: Huomasin, että ylhäällä oli jo vinkki ldd:n ajamisesta, jonka (tai jota vastaavan komennon) pitäisi kertoa, jos ongelma liittyy kirjaston olemassaoloon.
Mikäli ongelma ei liity kirjaston olemassaoloon tai virheeseen asennuksessa, niin melko luultavasti se on ongelma, jota ei kannata ratkaista, ellei ole 8th:n kehittäjä.
Alla oleva Python:ihan ei todista sitten kauheasti siitä, koska toki se voi toimia eri version libffi:llä, mutta 8th ei toimi.
Viittaisikohan https://8th-dev.com/forum/index.php?topic=2982.msg17266
---
Onkohan jotain väliä sillä, että kun latasin itse 8th:in niin ei tuolla /bin/ ole kuin rpi32-kansio eli 32-bittiselle RPi:lle? Luulin, että tuo alussa mainittu lankku on 64-bit prossulla. Oletin, että se lin64 on amd64:lle käännetty.
---
Vastaus alle: niin, no tuo libffi7:n puuttuminen olisi selvinnyt aiemmillakin ohjeilla, vaikka en muistakaan kaikkia detaileja ulkoa. On melko yleistä, että puuttuva kirjasto on toisessa repossa, kuten jossain "old"-repossa. On kuitenkin eri asia, että onko tällaista kirjastoa tarkoitettu käytettävän non-old -järjestelmissä, jonka takia asiaan ei kannata koskea, ellei ole 8th:n kehittäjä. Mikäli 8th:in kehittäjät tietäisivät asiasta, niin heillä olisi ohje, jossa sanotaan, miten toimia puuttuvan tai väärän version libffi:n kanssa.
Eipä tämä Metabolix:inkaan ohje tainnut olla ihan täsmällinen:
"Tuolla alussa kuitenkin jo näytit, että libc ilmeisesti saadaan jollain tavalla ladattua, kun siitä muodostuu jokin 8th:ssa käsiteltävä objekti. Eli olettaisin, että versionumerosta tai puuttuvasta kirjastosta ei ole kyse.", kun sitten jälkeenpäin ongelma näyttäisi olevan nimenomaan puuttuva kirjasto. Tämän olisi ehkä voinut päätellä tässä aiemmin olleesta muka-huonosta vinkistä.
Sitten on myös mahdollista, että mavavilj on tästä asiasta täysin kujalla ja voisi lopettaa alkeellisten "onko johto seinässä" -vinkkien jakamisen. Nämä viimeisimmät vinkit hyvin kertovat, että mavavilj ei tiedä Linuxin käytöstä kovin paljon. Vinkeissä olevien virheiden etsiminen jää kotitehtäväksi.
Metabolix kirjoitti:
(28.03.2025 19:13:57): Netissä väitetään, että libffi on myös...
Asensin äsken Pythonin ja ylläoleva Python koodi toimii kyllä.
Asensin Debianin mutta sama vika, eli pakettina löytyy vain libffi8 enkä pysty tätä ilmaisversiota nyt testaamaan. Minusta 8th:n julkisilla sivuilla on todella vajaasti kerrottu tuetuista järjestelmistä. Ongelmien juurisyy on varmaan joka tapauksessa siinä, että 8th on käännetty juuri tietylle Linux-jakelulle ja jokin keskeinen asetus tai kirjaston versio on sinulla erilainen sellaisella tavalla, että ohjelma kaatuu.
Oletko testannut Debiania, vaikka ei olekaan kiihdytystä? Voit kokeilla myös tuon jakelun sisällä, toimiiko debootstrapilla luotu Debian-chroot. Jos sekin toimii, varmistuu käytännössä, että vika on tosiaan kirjastojen yhteensopivuudessa.
Metabolix kirjoitti:
Oletko testannut Debiania, vaikka ei olekaan kiihdytystä? Voit kokeilla myös tuon jakelun sisällä, toimiiko debootstrapilla luotu Debian-chroot. Jos sekin toimii, varmistuu käytännössä, että vika on tosiaan kirjastojen yhteensopivuudessa.
Vanhempi Olimex:in Debian pohjainen asennus image toimii tällä täydellisesti.
Täytyy varmaan kokeilla Debian 12 beta imagea, minkä MYiR minulle lähetti.
Ei muuta kun kääntämään kerneliä
Asensin tämänhetkisen Raspbianin. (Tarkista itsellesi oikea arkkitehtuuri.)
DIR="$PWD/raspbian-chroot" mkdir "$DIR" debootstrap --arch armhf stable "$DIR" http://mirrordirector.raspbian.org/raspbian/ cp -a /opt/8th "$DIR"/opt/ systemd-nspawn -D "$DIR"
Siinä on tarjolla libffi6 ja libffi8. Tämä 8th:n Raspberry PI -tuki alkaa tuntua ihan vitsiltä.
Asensin sitten kiertoteitse vanhan libffi7:n.
sed -i "s/ stable / oldstable /" /etc/apt/sources.list apt-get update apt-get download libffi7 dpkg -i libffi7*.deb
Tämän kanssa 8th nyt vihdoin toimii ja myös seuraava testikoodi toimii toivotusti:
libc drop "NZ" "system" func: system : x chdir "echo ; pwd ; ls" system ; "/" x "/etc" x bye
Myös pystyn käyttämään tuota vanhan Raspbianin libffi7-kirjastoa Arch Linux ARMissa ja toimii.
Testasin sitten gdb:llä, mutta gdb:n kanssa 8th:ssa tulee Segmentation fault jo käynnistäessä. Samoin käy myös läppärillä ihan tavallisella x86_64-versiolla. Olisiko jopa kiusan vuoksi tehty debuggerin käyttö vaikeaksi, kun on kaupallisesta ohjelmasta kyse.
Jos haluaisin vakavasti selvittää tuon ongelman, varmaan ensiksi tarkistaisin vielä yllä olevalla debootstrap-metodilla, että 8th toimii kyseisellä laitteella ja kernelillä mutta Debianin kirjastoilla, ja sitten joko yrittäisin kopioida laitteistokiihdytykseen tarvittavat kirjastot toimivaan ympäristöön tai lähtisin debuggaamaan kaatumista esim. kääntämällä oman version libffi:stä.
Laitoin 8th kehittäjälle viestiä. Luulen, että 8th:n Linux binäärit on pakattu UPX:llä. Onkohan tämä se syy, mikä häiritsee gdb:tä?
Käännä itse
wy5vn kirjoitti:
Käännä itse
Oletkohan ikinä tehnyt custom Linux imagen vastaavalle raudalle? Ei sitä ihan tuosta noin vaan käännetä. Minun pitäisi opetella miten Yocto tai Buildroot toimii ja latailla useampia gigatavuja materiaalia.
Mielummin tällä kehitysraudalla käyttäisin valmistajan ajan tasalla olevaa imagea, missä on rautatuki valmiina ja ajan tasalla olevat kirjastot, jotka voin myös pitää ajan tasalla valmistajan toimesta.
On myös yleisesti ottaen hyödyllisempää saada 8th suoraan toimimaan mahdollisimman monessa ympäristössä.
Kyllä joskus. Olen harrastanut "Will it run Linux?" tyyppistä säätämistä. Kerran sain (ainakin melkein) linuxin pyörimään yhteen canonin järjestelmäkameraan.Siinä vaiheessa kun ei ole mitään dokumentaatioita mistään niin sitä voidaan jo kutsua haasteeksi.