Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Někde v temných uličkách a zákoutích internetu jsem si pořídil telefon Inhon G1 (lokální společnost, nenašel jsem anglickou verzi stránek), který je rozměry rozumně malý a výkonem dostatečný (4GB eMMC, 1GB RAM, 1GHz dvoujádro). Provozoval jsem na tom nějakou navigaci, poslouchal nějaké podcastí kecy a četl články (RSS + download, abych nemusel být stále připojen k netu).
I když jsem k tomu ale přidal paměťovou kartu, projevila se jedna drobná chybička, a to nedostatek paměti. On ten telefon má v základu pro uživatele dva oddíly: jeden ext4 "neviditelný", na který se ukládají aplikace a jejich data, druhý FAT, na který vidí/píšou aplikace ve skupinách sd_read a sd_write.
Pokud člověk přidá paměťovou kartu, sice na ni může ukládat uživatelská data, ale aplikace jako třeba ten Sygic, Google mapy nebo PodKicker pro ukládání dat nadále zvolí interní FAT nebo ext4 a místo tak lehce dojde, nehledě na to, že aplikace jde instalovat jenom na ext4.
Existují sice obezličky jako Link2SD, ale já jsem chtěl poznat, jak to vlastně přesně v tom telefonu vypadá a vůbec, když potřebuji víc místa na jednom diskovém oddílu, tak ho taky prostě zvětším a netvořím nějaké divoké symlinky z ext4 na FAT oddíl.
Můj plán byl následující: původní ext4 má něco přes 500MB, interní FAT něco přes 1GB (zbytek do 4GB jsou další skryté oddíly, o tom později), paměťovou kartu přímo využívá jenom foťák. Co kdybych spojil FAT a ext4 do jednoho ext4 a kartu používal způsobem, na který byl původně navržený interní FAT oddíl? Kartu neplánuji vyměňovat, zjednoduší se USB mass storage, které normálně ukáže buď jenom interní FAT nebo jenom SD kartu a budu mít kopec místa: 1.5GB na aplikace a 16GB na SD kartě na data.
Na tyto divokosti je potřeba root oprávnění, ty lze získat nahráním nějakého update.zip na paměťovou kartu a pak jej flashnout přes recovery mode (dostupné tak, že se při startu telefonu drží tlačítko pro přidání hlasitosti). Výchozí recovery ale kontroluje digitální podpisy a privátní klíč Inhonu bohužel nemám, ale dá se to obejít i tak, že se pomocí MediaTek flash tool nahraje jiný rescue mód (Taiwan ROM factory jeden takový založený na tuším Clockworkmodu přímo pro tento telefon má) a pak si můžu dělat co chci. Ten tool je sice jenom pro Windows, ale což, aspoň VirtualBox nezleniví (co jsem opustil jistý jablečný produkt, tak jsem se bál, že už jej nebudu potřebovat).
Když nastartujeme telefon do recovery režimu, pustíme adb shell
a v něm fdisk
, dosteneme něco, co mě napoprvé docela vyděsilo:
Disk /dev/block/mmcblk0: 3883 MB, 3883008000 bytes 1 heads, 16 sectors/track, 474000 cylinders Units = cylinders of 16 * 512 = 8192 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 3 2 2147483647+ 5 Extended Partition 1 does not end on cylinder boundary /dev/block/mmcblk0p2 2757 3396 5120 83 Linux Partition 2 does not end on cylinder boundary /dev/block/mmcblk0p3 4213 87284 664576 83 Linux Partition 3 does not end on cylinder boundary /dev/block/mmcblk0p4 87413 152948 524288 83 Linux Partition 4 does not end on cylinder boundary /dev/block/mmcblk0p5 153077 218612 524288 83 Linux
Nemám tušení, proč nejsou oddíly zarovnané na cylindry, proč jsou mezi nimi mezery nebo proč není v tabulce oddílů /dev/block/mmcblk0p6 (který je ale v /dev filesystému a je autodetekován přes vold jak by člověk očekával). Pokud tomu někdo rozumíte, napište do diskuze prosím Moje pracovní teorie je, že emulované cylindry nejsou platné a tudíž si výrobce mohl dovolit to zarovnat jinak a fdisk z busyboxu tomu nerozumí.
Druhá zajímavost je umístění rozšířeného oddílu hned na začátek a nastavení velikosti na -1, aby reprezentoval celou eMMC nehledě na její velikost. Pokud to někdo někde viděl, taky se podělte.
Každopádně, trochu jsem si s tím pohrál (mezi původním p2 a p3 jsou podle scatter.txt nějaké asi důležité data a tak jsem zachoval počátek systémového oddílu a pozici sec_ro -- pravděpodobně něco kvůli DRM nebo jinému šifrování) a tady se můžeme pokochat výsledkem:
Disk /dev/block/mmcblk0: 3883 MB, 3883008000 bytes 1 heads, 16 sectors/track, 474000 cylinders Units = cylinders of 16 * 512 = 8192 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 2757 3396 5120 83 Linux /dev/block/mmcblk0p2 4213 65536 490592 83 Linux /dev/block/mmcblk0p3 65537 98304 262144 83 Linux /dev/block/mmcblk0p4 98305 474000 3005568 83 Linux
vold
Výchozí nastavení vold
počítá se dvěma SD kartami (jedna emulovaná 1.5GB a druhá opravdová), kdy ta první je neplatná a druhá bude nově primární, tak potřebujeme změnit /etc/vold.fstab
. Původní nastavení je
dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-sd.0/mmc_host dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-sd.1/mmc_host
a nově jenom
dev_mount sdcard /storage/sdcard0 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-sd.1/mmc_host
Zdrojáky k jádru bohužel výrobce přímo neposkytuje (a to, co poskytují ostatní, jestli vůbec, je často neúplné a nejde přímo zkompilovat), tak si jádro upravíme svépomocí. Někde v jádru je tabulka, podle které se spojitou paměť eMMC mapuje na jednotlivé celky (jako třeba nvram, sec_ro, logo, ..., ale taky diskové oddíly, i když v tomto případě je ta informace zdvojená s údaji uvedenými v MBR), některé z těchto celků skončí v /dev/block/mmcblk0*
a na některé z nich se vytvoří symlink v /
, konkrétně vypadají takto:
shell@android:/ # ls -l /emmc* lrwxrwxrwx root root 1970-01-01 08:00 emmc@android -> /dev/block/mmcblk0p3 lrwxrwxrwx root root 1970-01-01 08:00 emmc@cache -> /dev/block/mmcblk0p4 lrwxrwxrwx root root 1970-01-01 08:00 emmc@fat -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 1970-01-01 08:00 emmc@sec_ro -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 1970-01-01 08:00 emmc@usrdata -> /dev/block/mmcblk0p5
Ale když jsme si už změnili rozdělení disku, tak tyto symlinky nebudou platné. Podobná tabulka v jiném případě vypadá takto (odsud a odsud):
struct excel_info PartInfoEmmc[PART_NUM]={ {"preloader",262144,0x0,0}, {"dsp_bl",1966080,0x40000,0}, {"mbr",16384,0x220000,0}, {"ebr1",376832,0x224000,1}, ... {"android",537919488,0x2004000,6}, {"cache",537919488,0x22104000,2}, {"usrdata",537919488,0x42204000,3}, {"fat",0,0x62304000,4}, {"bmtpool",10485760,0xFFFF0050,0}, };
V této struktuře si jádro pamatuje název bloku, velikost, adresu prvního bajtu a poslední číslo je buď nula (nevytvoří symlink) nebo číslo oddílu (podle fdisku), kam symlink povede.
Rozhodl jsem se najít v obrazu jádra binární reprezentaci této struktury (nebo podobné, zrojáky mám přeci jenom pro podobný model od jiného výrobce) a těch pár čísel upravit ručně v hexeditoru. Ale než se dostaneme k tomu, musíme jádro trochu zpracovat.
Obraz jádra je ve formátu pro uboot, tj. hlavička popisující zařízení a případné parametry jádra, pak jádro a initrd s initskripty a nejnutnějšími binárkami. Jelikož je tento formát relativně hojně používaný, existuje skript split_bootimg.pl na jeho rozsekání na jednotlivé kousky. Tak se do toho rovnou pustíme:
jan@bolt $ ./split_bootimg.pl boot.img Page size: 2048 (0x00000800) Kernel size: 3347584 (0x00331480) Ramdisk size: 598759 (0x000922e7) Second size: 0 (0x00000000) Board name: 20130830 Command line: Writing boot.img-kernel ... complete. Writing boot.img-ramdisk.gz ... complete.
Samotný kernel i ramdisk pak (v mém případě, podle různých tutoriálů usuzuji, že to není pravda na všech zařízeních) začíná 512-bajtovou hlavičkou popisující věci jako třeba identifikátor (KERNEL
nebo ROOTFS
) a velikost, tak ji oddělíme:
mv boot.img-ramdisk.gz boot.img-ramdisk dd if=boot.img-ramdisk of=boot.img-ramdisk.hdr bs=512 count=1 dd if=boot.img-ramdisk of=boot.img-ramdisk.gz bs=512 skip=1 dd if=boot.img-kernel of=kernel.hdr bs=512 count=1 dd if=boot.img-kernel of=kernel bs=512 skip=1
Kernel ale budeme muset dál rozpitvávat. To, co jsme totiž získali v kernel
, je totiž jenom krátký kód pro gunzip. Ten je 18404 bajtů dlouhý (zjistíme třeba vyhledáním identifikačních čísel podle specifikace gzip, tj. bajtů 0x1f a 0x8b).
kernel_size=`stat -c %s kernel` unpacker_head=18404 dd if=kernel of=kernel-aaa bs=$unpacker_head count=1 dd if=kernel of=kernel-payload.0 bs=$unpacker_head skip=1
Pak na konci (tj. za zkomprimovaným obrazem jádra) leží ještě nějakých 56 bajtů jiných dat, které si taky pro přehlednost oddělíme (velikost určíme automaticky srovnáním s rezipem):
gunzip < kernel-payload.0 > kernel-unpack gzip -9 < kernel-unpack > kernel-rezip.0 unpacker_tail=$(( `stat -c %s kernel-payload.0` - `stat -c %s kernel-rezip.0` )) rm kernel-rezip.0 payload_size=$(( $kernel_size - $unpacker_head - $unpacker_tail )) dd if=kernel-payload.0 of=kernel-zzz bs=$payload_size skip=1 dd if=kernel-payload.0 of=kernel-payload bs=$payload_size count=1 rm kernel-payload.0
Teď si konečně můžeme hrát s jádrem, jak ho gcc stvořil. Nejdřív najdeme tabulku těchto bloků eMMC -- to bohužel nejde podle textových identifikátorů, protože ty jsou uložené jinde a v tabulce bude jenom pointer na ně. Ale naštěstí ze scatter souboru nebo z fdisku víme hned několik čísel, které se v ní vyskytují: třeba android oddíl je na 0x026e8000, /cache
na 0x2b0e8000, pracovní ext4 na 0x4b1e8000 a uživatelská FAT na 0x6b2e8000 a tak po chvilce hledání v hexeditoru dostaneme něco velmi, velmi slibného:
jan@bolt $ hexdump -C kernel-unpack | grep -B5 -A5 '00 80 1e 4b' 0067e9c0 00 80 6e 02 00 00 00 00 01 00 00 00 03 00 00 00 |..n.............| 0067e9d0 00 00 00 00 00 00 00 00 28 cb 5a c0 00 00 00 00 |........(.Z.....| 0067e9e0 00 00 10 20 00 00 00 00 00 80 0e 2b 00 00 00 00 |... .......+....| 0067e9f0 01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 |................| 0067ea00 70 51 5c c0 00 00 00 00 00 00 10 20 00 00 00 00 |pQ\........ ....| 0067ea10 00 80 1e 4b 00 00 00 00 01 00 00 00 05 00 00 00 |...K............| 0067ea20 00 00 00 00 00 00 00 00 cc 50 5c c0 00 00 00 00 |.........P\.....| 0067ea30 00 00 00 00 00 00 00 00 00 80 2e 6b 00 00 00 00 |...........k....| 0067ea40 01 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 |................| 0067ea50 d4 50 5c c0 00 00 00 00 00 00 50 01 00 00 00 00 |.P\.......P.....| 0067ea60 a8 00 ff ff 00 00 00 00 01 00 00 00 00 00 00 00 |................|
Před adresou je velikost oddílu (třeba 0x02010000, resp. něco přes 512MB nebo 0x0 pro FAT, co předpokládám reprezentuje celý zbytek eMMC) a pár bajtů po této adrese máme i příznak pro symlink (před ním se ještě někdy z nějakého důvodu vyskytuje jednička, kterou jsem se rozhodl spokojeně ignorovat). Když změníme vše, co jsme zpáchali tak, aby to odpovídalo nové skutečnosti, dostaneme následující (změny jsou vyznačené):
0067e920 00 80 b8 01 00 00 00 00 01 00 00 00 01 00 00 00 |................| ... 0067e9b0 8c 02 5a c0 00 00 00 00 00 80 f1 1d 00 00 00 00 |..Z.............| 0067e9c0 00 80 6e 02 00 00 00 00 01 00 00 00 02 00 00 00 |..n.............| 0067e9d0 00 00 00 00 00 00 00 00 28 cb 5a c0 00 00 00 00 |........(.Z.....| 0067e9e0 00 00 00 10 00 00 00 00 00 00 60 20 00 00 00 00 |..........` ....| 0067e9f0 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................| 0067ea00 70 51 5c c0 00 00 00 00 00 00 00 00 00 00 00 00 |pQ\.............| 0067ea10 00 00 60 30 00 00 00 00 01 00 00 00 04 00 00 00 |..`0............| 0067ea20 00 00 00 00 00 00 00 00 cc 50 5c c0 00 00 00 00 |.........P\.....| 0067ea30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0067ea40 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Když jsme si to takto hezky pozměnili, potřebujeme to zase zakomprimovat, vložit do toho dekompresoru a to vložit do bloku dat pro uboot. Taky je potřeba zajistit, že zkomprimovaný obraz jádra bude stejně velký jako předtím -- po prvním pokusu zjistíme, že je trochu menší (nahradili jsme původní čísla trochu "kulatějšími" s více nulami), takže na konec dorazíme podpis -- ten nebude nic nikdy stejně číst, gunzip bude spokojený a já budu mít tři vlastní bajty v paměti telefonu (je ale potřeba trochu zkusmo zjistit, co je potřeba přidat na konec, aby se to zkomprimovalo na stejnou velikost).
gzip -9 < kernel-patched2 > kernel-rezip-patched cat kernel.hdr kernel-aaa kernel-rezip-patched kernel-zzz > mine.img-kernel ./mkbootimg --kernel mine.img-kernel --ramdisk boot.img-ramdisk \ --board 20130424 -o boot-mine.img
Pokud chceme taky změnit obsah ramdisku, můžeme si ho rozbalit a pak zase vytvořit:
mkdir ramdisk-stock cd ramdisk-stock gunzip < ../boot.img-ramdisk.gz | cpio -idv cd .. # patch... cd ramdisk-mine find . | grep -v '^\.$' | sort | cpio -ov -H newc -R root:root | gzip > ../mine.img-ramdisk.gz cd ..
Pokud je velikost jiná (což se typicky stane, pokud přidáme/odebereme/změníme nějaké soubory v něm), je to nutné taky opravit v hlavičce, aby uboot věděl (88168858 je magické čtyřčíslí, které identifikuje začátek bloku, po kterém hned následuje velikost):
function fsx() { printf "%.8x" `stat -c %s "$1"` | sed -E 's/(..)(..)(..)(..)/\4\3\2\1/'; } function repm() { sed 's/ 88168858......../ 88168858'`fsx "$1"`'/'; } xxd -g0 boot.img-ramdisk.hdr | repm mine.img-ramdisk.gz | \ xxd -r -g0 > mine.img-ramdisk.hdr cat mine.img-ramdisk.hdr mine.img-ramdisk.gz > mine.img-ramdisk
Já jsem nic moc neměnil, ale ty initskripty vypadaly lákavě
V datovém oddílu je uložen adresář nvram
, kam se ukládá stav telefonu před vypnutím (hlavně obsah paměti čipů pro bluetooth, wifi, telefonu, kalibrační data senzorů a podobně). Během popsaného procesu je potřeba jej zazálohovat a pak obnovit, jinak se ztratí mnoho užitečných informací. Pak se člověk diví, proč blbne signál nebo proč má divnou MAC adresu.
Docela jsem si pohrál, zjistil, jak android vypadá velmi těsně nad hardwarem, početl jsem si zdrojáky Mediateku (i když ne přímo na můj model) a mám mnohem víc místa na aplikace. Samé pozitiva a sociální jistoty prostě
Ještě by to chtělo si trochu pohrát se Settings.apk, které obsahuje informace o oddílech taky -- takto mi to zobrazuje SD kartu jako "interní paměť" a neustále hlásí, že SD karta samotná je nepřítomná (tj. nelze ani odmountovat apod.). To mi ale moc nevadí, protože ji stejně neplánuji vybírat a protože si na ni aplikace ukládají data, stejně by to nebylo moc ku prospěchu věci.
A možná někdy zaspamuji Inhon, aby mi poslali jejich verzi zdrojáků jádra (moc licencím nerozumím, jsou to povinni udělat?) a třeba si na to sestavím vlastní distribuci, včetně plnotučného linuxu.
Kdo to dočetl až sem a ví, o čem tu kvákám, si zaslouží plný respekt a má u mně během příštího Computexu (nebo jiné akce) pivo
Tiskni
Sdílej:
Tak to jsme dva
k cemu tak slozite kyz uz davno na to existuje appka .. ktera to udela ve dvou krocich ,....
+ k cemu na emmc zarovnavat na cylindry z rotacnich disku?
dej hledat MTK Repartition .. je primo app na repart eMMC u MTK telefonu .. a umoznuje nastavit tebou pozadovanou velikost s tim ze nejlepe funguje 2-2.5GB na data ...
napr ceky navod je zde http://androidforum.cz/riesenie-problemu-s-malou-vnutornou-pama-ou-2-t42983.html i s linky na DL app .
a nebo se podivat na XDA-dev..
Link2SD sem nepouzil od doby co ma zena rozbila sve ZTE Blade
to že si chceš hrát tě šlechtí ...
s SP flash toolem bych si moc nezahrával .. přece jen s ním natvrdo bricknout tlf není problém a slouží hlavně k servisní práci ...
+ta appka ma vyhodu ze jednou rozložené odíly fungují i s 90% rom a různými verzemi droida ,,,
jinak o TLF na MTK ví nejíc rusové a vietnamci .. good je třeba 4pda.ru