Po 9 týdnech vývoje od vydání Linuxu 6.14 oznámil Linus Torvalds vydání Linuxu 6.15. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
plwm je nový, poměrně minimalistický správce oken pro X11. Podporuje dynamické dláždění okny, plochy, pravidla pro okna atd. Zvláštností je, že je napsaný v logickém programovacím jazyce Prolog. Používá implementaci SWI-Prolog.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Sean Heelan se na svém blogu rozepsal o tom, jak pomocí OpenAI o3 nalezl vzdálenou zranitelnost nultého dne CVE-2025-37899 v Linuxu v implementaci SMB.
Jiří Eischmann v příspěvku na svém blogu představuje typy, jak lépe chránit své soukromí na mobilním telefonu: "Asi dnes neexistuje způsob, jak se sledování vyhnout úplně. Minimálně ne způsob, který by byl kompatibilní s tím, jak lidé technologie běžně používají. Soukromí ovšem není binární věc, ale škála. Absolutního soukromí je dnes na Internetu dost dobře nedosažitelné, ale jen posun na škále blíže k němu se počítá. Čím méně dat se o vás posbírá, tím nepřesnější budou vaše profily a tím méně budou zneužitelné proti vám."
Byla vydána nová stabilní verze 25.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Warbler. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Multiplatformní open source spouštěč her Heroic Games Launcher byl vydán v nové stabilní verzi 2.17.0 Franky (Mastodon, 𝕏). Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 26 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Klávesnice IBM Enhanced Keyboard, známá také jako Model M, byla poprvé představena v roce 1985, tzn. před 40 lety, s počítači IBM 7531/7532 Industrial Computer a 3161/3163 ASCII Display Station. Výročí připomíná článek na zevrubném sběratelském webu Admiral Shark's Keyboards. Rozložení kláves IBM Enhanced Keyboard se stalo průmyslovým standardem.
Vyšlo Pharo 13 s vylepšenou podporou HiDPI či objektovým Transcriptem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Odkazy
Dnešný mikroblog je určený tím, ktorí by potrebovali čítať sériové číslo na týchto SoC, alebo tým ktorých zaujíma ako sa vôbec sériové číslo SoC číta / zapisuje.
Sériové číslo (alebo presnejšie povedané root kľúč 0-3) je na SoC allwinner zapísané v eFUSE pamäti namapovanej do fyzickej pamäte pod základnou adresou 0x01c23800
. Podľa dokumentácie je do tejto pamäte možné zapísať prakticky ľubovoľných 128 bitov dát. K zápisu je však potrebné fyzicky odpojiť pin EFUSE_VDDQ od GND a pripojiť ho na určité napätie (detaily nepoznám). Na čítanie nie je potrebná žiadna modifikácia hardvéru a root kľúče 0-3 by mali byť zapísané priamo výrobcom (niekedy sú v tejto pamäti zapísané samé nuly).
Názov registra | Offset | Veľkosť |
---|---|---|
SID_KEY0 | 0x00 | 4 B |
SID_KEY1 | 0x04 | 4 B |
SID_KEY2 | 0x08 | 4 B |
SID_KEY3 | 0x0c | 4 B |
SID_WRITE_DATA | 0x40 | 4 B |
SID_WRITE_CTRL | 0x44 | 4 B |
Pre nás zaujímavú časť môžme zapísať nasledujúcou štruktúrou v C:
typedef struct DeviceSID { uint32_t key0; uint32_t key1; uint32_t key2; uint32_t key3; } DeviceSID;
Zariadenia sú priamo mapované vo fyzickej pamäti. V užívateľskom priestore nie je možné pristupovať do fyzickej pamäte pretože všetky adresy sú virtuálne. Prístup do fyzickej pamäte sa dá zabezpečiť len namapovaním časti fyzickej pamäte do virtuálnej pamäte užívateľského procesu volaním mmap. Offset musí byť zarovnaný na veľkosť stránky čo je v tomto pípade 4096B (212). Počiatočnú adresu môžme zistiť buď v referenčnej dokumentácii alebo hrabnutím do zdrojových kódov kernelu. Pre nás zaujímavou konštantou je SW_PA_SID_IO_BASE (0x01c23800)
.
#include <stdlib.h> #include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <stdint.h> #include <sys/mman.h> #define IO_BASE_ADDRESS 0x01c00000 #define SID_BASE_ADDRESS 0x01c23800 #define IO_SIZE 0x00300000 #define SID_MMAP_START ((SID_BASE_ADDRESS >> 12) << 12) typedef struct DeviceSID { uint32_t key0; uint32_t key1; uint32_t key2; uint32_t key3; } DeviceSID; int main(int argc, char *argv[]) { int fd; // prístup do fyzickej pamäte z userspace je možný cez /dev/mem if ((fd = open("/dev/mem", O_RDONLY | O_SYNC)) == -1) { return -1; } // volatile nie je nutné, ideme čítať statické dáta void *io = mmap(0, 4096, PROT_READ, MAP_PRIVATE, fd, SID_MMAP_START); if (io == MAP_FAILED) { close(fd); return -2; } // prečítaníe SID DeviceSID serial; serial = *(DeviceSID *)(io + (SID_BASE_ADDRESS - SID_MMAP_START)); // upratovanie if (munmap(io, sizeof(DeviceSID)) == -1) { close(fd); return -3; } close(fd); printf("%04x-%04x-%04x-%04x\n", serial.key0, serial.key1, serial.key2, serial.key3); return 0; }
V príklade sa mapuje celá stránka veľkosti 4kB. Ak by som modifikoval main funkciu nasledovne:
// ... void *sid = mmap(0, sizeof(DeviceSID), PROT_READ, MAP_PRIVATE, fd, SID_BASE_ADDRESS); if (sid == MAP_FAILED) { close(fd); return -2; } DeviceSID serial; serial = *(DeviceSID *)(sid); // ...
kernel by pri pokuse o mmap vrátil errno EINVAL
.
To by bolo z dnešného malého problému s A13 hádam všetko, nabudúce skúsim niečo záživnejšie ako je hardvérové dekódovanie videa na A13 (mimochodom v cene A13 + napájacieho obvodu je aj poplatok za h.264, celé to stojí 5.35€ / kus pri fakt veľkej objednávke).
Tiskni
Sdílej:
No ono to nie je s oficiálnymi drivermi žiadna sláva. Síce to dokáže dekódovať kadečo, ale linuxové knižnice sú totálne odfláknuté a ani najobyčajnejšie h.264 nedokáže prehrať bez --weightp 0
pri enkódovaní h.264. Open source implementácia knižníc je na tom čo sa týka podpory h.264 lepšie ale dekóduje zatiaľ málo formátov.
ani najobyčajnejšie h.264 nedokáže prehrať bez --weightp 0
pri enkódovaní h.264
Hehe... náhodou touhle funkcí se ta krabička vyrovnává kvalitě AppleTV nebo iTV nebo jak se ta jejich pytlovina jmenuje. :)
V príklade mapujem celý I/O priestor pretože kernel nedovolí mapovanie kdekoľvek.Nestačilo by mapovat jednu stránku (4096 bajtů)?
Skúšal som mapovať časť I/O, ale žiaden offset v I/O mi mmap neakceptoval (EINVAL).
Jej UIO je pekné. To si musím vyskúšať. Pôvodne som chcel hodiť do kernelu dtsi pre moju dosku, ale toto vyzerá o dosť pohodlnejšie.
Filter access to /dev/mem (CONFIG_STRICT_DEVMEM)
, co omezuje přístup jinam než do mapované paměti periférií a (u PC) paměti BIOSu. Je tedy možné, že na ne-PC platformách, kde není v dispozici mapa paměti ani enumerace zařízení, nebude /dev/mem
k přístupu k MMIO použiutelné.
Po zarovnaní na 4kB skutočne ide, neviem prečo sa mi zdalo 0x01c23800 zarovnané. Dik za upozornenie.
Supporting Allwinnner SoCs ootb will require kernel and u-boot support. Kernel support is landing upstream and we will add patches to the Fedora kernel for 1-2 kernel releases to supplement this. u-boot support currently lives in a u-boot fork upstream, this fork is tracking / merging u-boot upstream and does intent to get sunxi support merged into the official u-boot packages, but there is no timeline for this atm. For u-boot we will create a separate u-boot-sunxi package, which can be dropped once u-boot support has been merged into u-boot upstream.
> Přijde mi, že se tady plete pár pojmů - jednak ta fedoří změna vypadá na zapracovávání věcí z linux-sunxi.org To ovsem nema s upstreamem nic spolecneho, takze to lze ignorovat. > které se do upstreamu jedna po druhé dostávají A dela to presne jeden clovek, cili naprosta minorita zbytku, ktery urputne tvrdi, ze na upstream kasle.Stále mi přijde, že si nerozumíme: zrovna Hans má nějakou historii přispívání do hlavní řady kernelu a i nějakou historii dotahování věcí do funkčního stavu, takže když píše, že cílem je postupně dostat hw podporu AW zařízení do hlavní řady, tak mu věřím, že to dřív nebo později zvládne. Ten "fork" pak beru jako cestu, aby nalákal další vývojáře k přispívání, aby celá věc šla rychleji (= aby na začleňování věcí do hlavní řady dělalo víc lidí než Maxime a spol.).
Rád by som, ale pracovne som maximálne vyťažený, nemôžem si dovoliť. V každom prípade rýpanie do u-bootu ma ešte len čaká. Bootovanie z SD karty je v pohode, ale bootovať kernel z NAND som ešte neskúšal.