apal blogja

Szembejött a minap egy egyszerűnek látszó hekkelési probléma. Beágyazott program, RISC architekúra (konkrétan MSP430X), volt benne egy efféle

if ( feltetel )
 {      a=csinalj(ezzel,0);
        b=meg_ezzel();
        valamit(a);
        es_megvalamit(b);
 }

rész, és ezt kellett kiiktatni úgy hogy a binary image-be kellene (távolról) beleírni ezt-azt hogy ugorja át ezt az egész blokkot. Sajnos a "feltetel" nem volt azonosan 0-ra írható sehogy (saját design flaw, lásd még: aki hülye, nem kap fagyit), így maradt az hogy egy jól irányzott "jmp" beszúrása az "a=csinalj(ezzel,0)" helyének elejére, ami az es_megvalamit(b); után ugrik. Mindezt úgy hogy a binary image ne módosuljon (azaz ne csússzon el) és lehetőleg csak ott a blokk elején kelljen pár byte-ot átirni.

Van azért egy kis szépség a természetes intelligenciában is.

Az I/O portos dolgok "rendbetetele" utan gondoltam megnezem mi a helyzet a regiszterekkel. Merthogy ez a sajat implementacio reszben a Navre projekten alapult, ami ezt az egesz "register file" temakort relative egyszeruen letudta. Konkretan ott a regiszterek egy sima `reg [7:0] GPR [0:31]` jellegu tombben vannak es a execute-writeback ciklusban mindenfele gombaramkor kikanalazza ebbol azt ami kell - azaz 1, 2, neha 3 regiszter erteket - es visszairja azt ami kell, szinen 1, 2, neha 3 regisztert. Ez igy oke is lenne, megy is, de ket hatranya van: egyreszt, az FPGA-kban a multiplexerek, noplane a 32:1 multiplexerek dragak (lassuak is es zabaljak is a LUT-okat). Masreszt meg mar a legegyszerubb FPGA-kban is van valamifele embedded block RAM es milyen jo lenne ezeket is felhasznalni a CPU-n belul is. Mondvan hogy egy AVR-ben is azert 256 bit megy el csak a GPR-ekre - a 32:1 multiplexerekrol meg mar ne is beszeljunk.
 

Google maps: 3d globe view nem mukodik cookie problemak miatt egy ideje. Inkognitoban megy. Vagyis, ment eddig. Most a 27ik motorcycle/firehydrant/stairs/trafficlight AI-tanitas utan meguntam ezt az egesz hulladekot. Ha barkinek van barmi otlete hogyan lehetne ezt a szart hasznalni, ne habozzatok... koszi! 

Egy kicsit zavart hogy a soft AVR core-s projektben ez az egyebkent elegge AVR-specifikus, 6 bit mely, 8 bit szeles I/O buszt a CPU aszinkron modon olvassa es szinkron modon irja. Azaz mig a program-memoria illetve az adatmemoria rendes szinkron ROM/RAM-kent viselkedik (igy mind az olvasasi, mind az irasi ciklus eredmenye a kovetkezo orajelre jelenik meg a CPU es/vagy a memoriak szamara), az I/O port eseten az olvasas a jelenlegi implementacioban aszinkron. Gondoltam kicsit utanajarok ennek a dolognak mit lehet itt tenni hogy egy elegansabb, jobban fenntarthato, jobban ujrafelhasznalhato cuccmany legyen ebbol az egeszbol. 

just for the record:

https://stackoverflow.com/questions/52998331/imagemagick-security-polic…

avagy:

$ convert papir1.jpeg papir1.pdf
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/426.

# apt-get install gtk3-nocsd
$ export GTK_CSD=0
$ export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
$ gtkwhatever ... 

... csak mert nehany alkalmazasnal kimondottan hulyen mukodik ez a "client-side decoration" nevu baszmany... Ezzel a fenti hekkelessel mar egy fokkal vallalhatobb, de persze igy is jobb volt mint lett. Pl ez a Ξ jellegu menuzes is joval kevesbe hatekony mint a szokasos menurendszer eles hasznalat eseten (ha valaki tudja hogyan lehet azt visszaallitani, akkor szoljon :)).

Érdekes megállapítás: gcc-12 esetén RISC-V processzorokra a -march= kapcsoló már elkezd különbözni fordítás és linkelés esetén. Amennyiben speciálisabb Zxxx kiterjesztést használunk (azaz bármi CSR-t, azaz ilyen-olyan megszakításokkal dolgozunk!), akkor azt immáron már "kéri" a fordító, ellenben a linker meg meghülyül ha ottmarad ez.

Onnan is lehet látni hogy az Unicode karakterkészletet Ámerikában találják ki hogy a "mosógép" még mindig nincs a karakterek között, de "egy zászlópóznán, a szélben lengedező két darab döglött hal" (🎏) az van!

Egy kicsit intenzívebb fejlesztési szakasz és néhány korábban felmerült kérdés után kijött a korábban bemutatott, saját fejlesztésű AVR proci és/vagy SoC következő verziója. Javítva vagyon benne pár CPU core és perifériákat érintő bug, ami a tesztek során ugyan előjött, de jelenlegi felhasználásnál (azaz konkrét programok futtatásánál) nem jött elő, sem égen, sem földön.

Noha az "digitális elektronika" mint olyan arról lehet nevezetes hogy egyik állapotot egyértelműen kell kövesse a következő állapot, a hardver-leíró nyelvek közül is a Verilog szereti használni a sztenderd "0" es "1" (és "z") állapotokon felül az "x"-et. Ami... ami úgy van definiálva mint: nem tudjuk, nem érdekel, nem érint, vagy ennek valamiféle kombinációja. Szeretjük is használni az "x"-et már "beugró szinten is", már a legegyszerűbb igazságtábláknál is megjelenhetnek.
 

Kis hasznos az /etc/udev/rules.d/ konyvtarba, ha valaki sok FTDI USB UART-tal dolgozik:

SUBSYSTEM=="tty", ACTION=="add", RUN+="/bin/bash -c 'f=/sys/bus/usb-serial/devices/%k/latency_timer; test -f $f && echo 1 > $f'"

Kicsit gyanus volt hogy 921k6 baudon az oda-vissza tranzakciok ~12kB/sec-cel mentek... :)

struct __attribute__((__packed__)) whatever
 {      unsigned int  f1: 2;
        unsigned int  f2: 5;
        unsigned int  f3: 5;
        unsigned int  f4: 6;
        unsigned int  f5: 6;
        unsigned int  f6: 8;
 };

[...]

sizeof(struct whatever) = ?

$ top
[...]
 2983 apal      20   0  1.103t 277496 118228 R 176.2  1.7   0:08.10 chrome                                                             
 2502 apal      20   0 32.807g 320464 208048 S  21.8  2.0   0:16.80 chrome                                                             
 2939 apal      20   0  1.103t 188632 108684 S  21.8  1.2   0:02.02 chrome                                                             

Not bad... 

Márcsak szűk két óra: https://www.nasa.gov/nasalive

... tavaly sikerult beleplnem. Iden mar nem. Gondoltam megirom hosszabban is a tapasztalatokat, de aztan a gondolat tovaszallt - mondvan hogy valojaban sok ujat nem tudok mondani eme szoftverceg minosegerol. Mondjuk mar tavaly osszel is volt annyi sutnivalojuk a bizottsagoknak hogy a doktori vedesek es/vagy szigorlatok egyreszet attettek zoom-ra. Azaz van feny az alagut vegen, de a holnaputani esemenybol vsz igy meg es/vagy mar sokan kimaradunk.

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

... 

Márcsak kevesebb mint 11 óra! https://www.youtube.com/watch?v=J1nfIV-4_e8

Két kicsi magyar műhold, reméljük minden is rendben lesz :) A videó moszkvai időt mutat, magyar idő szerint szombat reggel 07:07-kor indulunk. (Node a mi visszaszámlálónk az csak-csak jó... bár a javascript sosem tartozott a kedvenc nyelvek közé, odafent azért nem azt kell használni)

Szerk: egy nap halasztás, start vasárnap reggel! két nap halasztás, lesz ez hétfő reggeli start is.

2020 vege, vegytiszta szuz android, chrome-mal, webes email attachment: ~2 megas jpeg. 

Elso sajat opencores-projekt: https://opencores.org/projects/softavrcore. Ha valakit erdekel full stack FPGA + AVR kombinacio. 

Kovetkezo feladat: hogyan is lehet svn-ben(!) ilyen dolgokat feltolteni a barhova is...

# ls -l /dev/md
lrwxrwxrwx 1 root root 8 Jun 15 17:22 md0 -> ../md127
 

... es mekkora orom amikor kiderul hogy a javascript a style.zIndex-eket stringkent hasonlitja ossze!

... es akkor ott bassza meg a pötterix onmagat ahol van!

Van egy USB3-Ethernet adapter, amit ha egyik USB-A 2-es csatlakozoba dugok akkor minden oke, de ha a masikba (ami konkretan egy USB2-es hub egyik vagy masik csatlakozoja) akkor nem mukodik csak ugy. A dmesg szerint az enumeration elejen mar elekad (de konkret hibat nem irt ki). Ellenben ha csak ugy felig dugom be hogy eppenhogy legyen kontakt, akkor szepen megy - ellentetben mechanikailag annyira nem tartos a dugvany.

Akkor ezekszerint ez az USB3 vs. USB1/2 hardveres szintu csatlakozo-kompatibilitas az igy sikerult? Eszi, nem eszi, nem kap mast? :)

... hogy az is egy kellemes erzes mikor kiderul ~fel nap debuggolas utan hogy a gray code -> binaris konverzio elott nem lehet csak ugy ad hoc negalni az osszes bitet :) Avagy: legkozelebb ne doljunk be az "ah, open collectoros a gray-enkoder kimenete, tokmindegy hogy hogy vesszuk le azokat a biteket" dolognak!