- Meggyőző arcjátékkal reagál a kínai humanoid robot
- Letartóztatták, mert AI segítségével csalt az egyetemi vizsgán
- Hálózati / IP kamera
- Milyen program, ami...?
- DIGI internet
- Synology NAS
- Az AI miatt vehetnek sokan új iPhone-t
- ASUS routerek
- Újabb államok perelik az Apple-t, mert sok pénzt szed ki a vevőkből
- Microsoft Outlook topic
-
IT café
Utoljára frissítve: 2024.03.06.
Légy szíves olvasd el mielőtt kérdezel!
Az összefoglalóban sok helyen a fórumtársak hozzászólásai vannak belinkelve, vagy az ő információik alapján írtam meg, tisztáztam le az adott információt. Ezúton is köszönöm mindenkinek a segítséget!
Új hozzászólás Aktív témák
-
Pelican
őstag
válasz kovakovi77 #57253 üzenetére
Csinálhatnál egy próbát a CE-vel is.
Az armbian jelszó valami egyszerű volt mint 1234, de már nem emlékszem biztosan.http://pel.hu/eoscard http://pel.hu/bdedit
-
blakey
titán
válasz kovakovi77 #57253 üzenetére
Majd próbáld ki a CE-t.
Armbian jelszó :1234*** "Ne kérdezz többet, mint amennyi a hasznodra válik." - Dante *** "Csak akkor tehetsz meg mindent, ha már semmid sincs." - Harcosok klubja ***
-
Csicsóka
őstag
válasz kovakovi77 #57253 üzenetére
Nagyon is elképzelhető, hogy az atvX-es image-ban más U-boot van, és cseréli azt is flasheléskor.
Így akár a CE is elindulhat. Ha mégsem, akkor az eltérő boot metodus miatt nem.
Az Armbian használ még s905_autoscript-et, és ebből tölti be külön, külön a kernelt, és az initrd-t.
Itt látszik, hogy szépen sorba nézi a 4 USB-t, majd megtalálja az SD-n, és ahogy látom az x96-max.dtb-t választottad, ezt kiolvassa az uEnv.ini-ből majd indítja a rendszer.reading s905_autoscript
1765 bytes read in 6 ms (287.1 KiB/s)
## Executing script at 01020000
** Bad device usb 0 **
** Bad device usb 1 **
** Bad device usb 2 **
** Bad device usb 3 **
reading zImage
20658184 bytes read in 1153 ms (17.1 MiB/s)
reading uInitrd
7887925 bytes read in 444 ms (16.9 MiB/s)
reading uEnv.ini
207 bytes read in 6 ms (33.2 KiB/s)
reading /dtb/meson-g12a-x96-max.dtb
42641 bytes read in 9 ms (4.5 MiB/s)
[rsvmem] get fdtaddr NULL!
rsvmem - reserve memory
Usage:
rsvmem check - check reserved memory
rsvmem dump - dump reserved memory
rsvmem check failed
## Loading init Ramdisk from Legacy Image at 13000000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 7887861 Bytes = 7.5 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
load dtb from 0x1000000 ......
Amlogic multi-dtb tool
Single dtb detected
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
[rsvmem] fdt get prop fail.
Loading Ramdisk to d36e8000, end d3e6dbf5 ... OK
Loading Device Tree to 000000001fff2000, end 000000001ffff690 ... OK
Starting kernel ...A CE nem így indul. A kernel.img valójában nem csak maga a kernel, hanem egy AOSP kompatibilis Android boot image, amiben benne van a kernelen kívül az initrd is. Ezt a megoldást valszeg a boxokhoz való maximális kompatibilitás miatt választotta anno a OE. Korai **MC-nél én is az Armbian féle módon indítottam, de volt pár S905x vas, amin csak részlegesen ment a rendszer. Ezért lett a végén módosított LE indítási mód.
Egyszóval, ha nem fog elindulni a CE, akkor csak az Armbian, és CE eltérő mószere miatt lehet.[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #57335 üzenetére
Fő eltérés az LE, és CE közt megint csak az indítási folyamatban van. Az LE aml_autoscript beilleszti az U-boot változók közé az s905_autoscrip-et, majd rebootol. A CE aml_autoscript egyből módosítja a változókat, és nem rebootol, azonnal indítja a kernelnek nevezett boot image-t. Egy jó ideje a CE már nem használ s905_autoscrip-et. Ezzel a próbával az tisztázódott legalább, hogy mind az Armbian féle, külön kernel + initrd, mind az android boot image használható megoldás. Egyedül a CE féle boot image nem tetszik neki valamiért.
adamg a csapatból, lehet hogy megoldja majd. -
Csicsóka
őstag
válasz kovakovi77 #57360 üzenetére
Meglehet hogy erre allergiás, és elindul ha a CE boot image-t is s905_autoscript-el töltöd be.
Ezt legegyszerűbben úgy tudod kipróbálni, ha az LE SD-t vagy USB-t használod erre. A CE SD-ről rámásolod a KERNEL, és SYSTEM-t felülírva az LE fájlokat. A dtb könyvtárba pedig azt a dtb-t másolod a CE SD-ről, ami a vashoz való. Az uEnv.ini-be pedig azt a nevet írod, és már is mehet a próba.Ugyan ezt meglehet tenni a MultiBoot rendszerrel, mert ott is az u-boot.script indítja el a boot img-t, (lehetne a neve s905_autoscript, de a név lényegtelen, ami benne van az számít)
A kérdés itt csak az, hogy s905x2 vason elindul e a multibbot, mert ez még nem létezett amikor foglalkoztam vele. -
Pelican
őstag
válasz kovakovi77 #57712 üzenetére
Írtam PÜ-t CE élesztéssel kapcsolatban.
http://pel.hu/eoscard http://pel.hu/bdedit
-
Csicsóka
őstag
válasz kovakovi77 #57712 üzenetére
Ezt a meggondolatlan kijelentést én is olvastam reggel, de mentem grillezni és nem volt időm reagálni rá.
Nem kéne hülyeségeket terjeszteni, mert ha zárt lenne az u-boot, képtelen lenne más rendszert indítani. Ezt már a múltkor kitárgyaltuk pedig. Ezt nem próbáltad? Így nem indult el a CE? -
Pelican
őstag
válasz kovakovi77 #57748 üzenetére
Köszi, továbbítottam.
Ez mindenképp a kernel kódolásra utal.:
[imgread]szTimeStamp[2019030117075114]
[imgread]secureKernelImgSz=0xe1a000
aml log : R-2048 check pass!
aml log : R2048 check pass!
aml log : R2048 check pass!
aml log : R2048 check pass![ Szerkesztve ]
http://pel.hu/eoscard http://pel.hu/bdedit
-
Csicsóka
őstag
válasz kovakovi77 #57738 üzenetére
Akkor ebből legalább megtudtuk, hogy s905_autocriptel betöltve sem megy a CE kernel. Most már biztos, hogy ott kell majd a problémát keresni.
A multiboot induláshoz nem sok reményt fűztem, ott még 3-as kernel van, és az uInitrd-ben a hozzá való pár modul. Elképzelhető, hogy az x2 vasak nem is tudnak 3-as kernellel működni. De ha tudna is, nincs hozzá megfelelő dtb. A nélkül meg megint fújhatjuk. Ránézek majd a logokra, amit feltöltöttél, hátha észre veszek vmit. -
Pelican
őstag
-
RedSwallow
tag
válasz kovakovi77 #57759 üzenetére
Én is A95X Max tulaj lettem, sajnos a Horizon Go kikapcsolt root mellett sem játssza le a csatornákat, de a torrent letöltés szépen megy winyóra, afrD is fut ahogy kell. A módosított Kodi amit adtak hozzá kuka (MX player tökéletes), a YouTube viszont engedi a 4K lejátszást. Szerintem csúnya az alap Launcher, le is cseréltem. Nem ragaszkodnék az Androidhoz, de azért használható így is.
kovakovi77! Ha tudok segíteni, hogy legyen működő CE, akár csak egy pár sörrel is, szólj
[ Szerkesztve ]
-
yotzo
csendes tag
válasz kovakovi77 #57903 üzenetére
A95X MAX-é
u211-ként látszik bebootolva, de x96-os dtb-vel elindul pl CEUgyanakkor ha ezekkel a dtb-kkel próbálok bootolni, akkor csak fekete kép és semmi eredmény. Az este nekem is sikerült megvágni, de ugyanaz mint a tieddel. Azért köszi a bajlódást. Többet most sajnos nem tudok, mert utazok és nem lesz nálam a box.
-
yotzo
csendes tag
válasz kovakovi77 #57906 üzenetére
Az is az, (mmint a /dev/dvb) csak 256k, és jóval később kezdődik az érdemi tartalom. Először én se értettem mi van, mert mindenki csak azt írta onnan kicopyzod és jóidő. Hát, majdnem.
Viszont nekem egy hétig nem lesz elérhető távolságban, így addig. rátok marad a feladat :-)[ Szerkesztve ]
-
Pelican
őstag
válasz kovakovi77 #58049 üzenetére
Már van akinek működött: https://discourse.coreelec.org/t/a95x-max-s905x2-cannot-boot-ce/6207/41?u=pelican
http://pel.hu/eoscard http://pel.hu/bdedit
-
kovakovi77
tag
válasz kovakovi77 #58056 üzenetére
Újra itt.
Nekem valami nagyon felre mehetett ezzel a boxal :)
Wifi/Bt- vadaszat még folyamatban de, hogy a Sata vezérlőm se akar menni CoreElec alatt….
Egyik forum társ már irt, hogy neki megy, elvileg ugyan az a boxunk, nekem sajnos nem műkszik.
A95X Max V81-verzio.
Android alatt szépen látja az ntfs-re formázott ssd-t CoreElec alatt rá se hederít.
Mellékelten itt pár kimenet amit néztem lsusb,lsblk,lsmod,dmesg.
sda1 jelen esetben a pendrive amiről a CoreElec fut, sdb létre sem jön a /dev/-alatt.
Rá néznétek mit nem látok? Esetleg miket próbáljak még meg?
Haza érve ránézek az usb-n csücsülő sata chipre, hogy milyen típus került ide beépítésre.
https://drive.google.com/file/d/105jcy5Z45ETIiRYRXBJbgFup6eSoMUkt/view?usp=drivesdk -
Ejelhar
senior tag
válasz kovakovi77 #58097 üzenetére
Hát ... ez nem valami biztató.
Az USB-n nem is lát semmilyen blokkos eszközt az sda-n kívül.A journalctl -f parancs mitet mond amikor rádugod?
-
Ejelhar
senior tag
válasz kovakovi77 #58103 üzenetére
Ebben nem látok semmit ami az USB interfészre utalna.
Úgy kéne, hogy ssh a boxra, journactl -f parancs kiad, majd rádugni az eszközt.
Hátha az online monitorozás segít megfejteni miért nem megy, hol akad el. Vagy legalább ad tippet merre kéne keresgélni a hibát.
Nálam pl. (egy NTFS-re formázott USB-s disk csatlakozásának naplója):DDS-Kodi kernel: usb 1-1.2: new high-speed USB device number 4 using xhci-hcd
DDS-Kodi kernel: usb 1-1.2: New USB device found, idVendor=174c, idProduct=1153
DDS-Kodi kernel: usb 1-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
DDS-Kodi kernel: usb 1-1.2: Product: AS2115
DDS-Kodi kernel: usb 1-1.2: Manufacturer: ASMedia
DDS-Kodi kernel: usb 1-1.2: SerialNumber: 00000000000000000000
DDS-Kodi kernel: usb-storage 1-1.2:1.0: USB Mass Storage device detected
DDS-Kodi kernel: scsi1 : usb-storage 1-1.2:1.0
DDS-Kodi kernel: scsi 1:0:0:0: Direct-Access ASMT 2115 0 PQ: 0 ANSI: 6
DDS-Kodi kernel: sd 1:0:0:0: [sdb] Spinning up disk...
DDS-Kodi kernel: .ready
DDS-Kodi kernel: sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
DDS-Kodi kernel: sd 1:0:0:0: [sdb] Write Protect is off
DDS-Kodi kernel: sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00
DDS-Kodi kernel: sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
DDS-Kodi kernel: sdb: sdb1 sdb2
DDS-Kodi kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
DDS-Kodi systemd[1]: Starting Udevil mount service...
DDS-Kodi systemd[1]: Starting Udevil mount service...
DDS-Kodi udevil[13701]: Mounted /dev/sdb1 at /media/ACRONIS HM
DDS-Kodi kernel: fuse init (API version 7.22)
DDS-Kodi systemd[1]: Mounting FUSE Control File System...
DDS-Kodi systemd[1]: Mounted FUSE Control File System.
DDS-Kodi systemd[1]: Started Udevil mount service.
DDS-Kodi ntfs-3g[13750]: Version 2017.3.23 external FUSE 29
DDS-Kodi ntfs-3g[13750]: Mounted /dev/sdb2 (Read-Write, label "DDS-T2", NTFS 3.1)
DDS-Kodi udevil[13700]: Mounted /dev/sdb2 at /media/DDS-T2
DDS-Kodi ntfs-3g[13750]: Cmdline options: big_writes,fmask=0133,uid=0,gid=0,utf8
DDS-Kodi ntfs-3g[13750]: Mount options: utf8,allow_other,nonempty,relatime,default_permissions,fsname=/dev/sdb2,blkdev,blksize=4096[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58103 üzenetére
Pedig a HK is ezt a chipet használja ebben.
Kár hogy az UAS módot ezek szerint nem tudja.
Csak azt kéne kideríteni, hogy milyen kernel modult használ, és bele kérni a következő CE-be, fixen, vagy modulban. Lehet jobb lett volna ha valamelyik Jmicron, vagy Asmedia chip kerül bele, bár a kínaiak azzal főznek ami nekik van, és olcsó.[ Szerkesztve ]
-
Pelican
őstag
válasz kovakovi77 #58193 üzenetére
Szerintem dtb gond lesz, valamelyik io-n kapcsolgatja a tápot, ami CE alatt nincs definiálva...
http://pel.hu/eoscard http://pel.hu/bdedit
-
RedSwallow
tag
válasz kovakovi77 #58103 üzenetére
Most volt egy kis időm megnézni, nekem is GL3321G chip van benne. Etcherrel kiírtam Coreelec-et, g12a_s905x2_4g_1gbit.dtb-t átneveztem és kimásoltam a gyökérbe, hiba nélkül indult és kezeli a hdd-t alapból, amin több NTFS partíció van(ahogy lehúztam a laptopról) le is játssza róla a filmeket. Nem tudom nálad mi lehet a gond.
-
kovakovi77
tag
válasz kovakovi77 #58193 üzenetére
Meg lett a probléma oka, de hihetetlennek tünik számomra.
Nos nállam a box-ra még a kezdet kezdetén felkerült egy AtvX3-rom.
Viszont ahogy jöttek a hírek, 2-fajta alap rom is piacon van igy AtvX3-ból is 2 készült.
Én a V10-es nyákra valót dobtam fel müködött minden amit teszteltem.
Majd CE-nél tünt fel, hogy hdd-t nem lát.
Se LE se Armbian.
2 forum társnak is V81-es lapja van és nekik megy a hdd CoreElec alatt, teljesen ugyan azt a verziót használjuk ugyan azzal a dtb-fileal.
0V-ot mértem a hdd Csatiján Labortápról kapott az ssd +5V-ot és igy működött.
Lapra dugva a táp csatit csak android alatt.
Ekkor tünt fel, hogy Android alatt a BT-sem megy, be sem lehet kapcsolni gyors utánna járással lekaptam egy V81-re készült Rom-ot mivel ebben az 1 dologban tért el az enyém a többiekétől.
Fel telepítve hdd-csati is életre kelt CE alatt.
Vissza dobva a rossz romot a hdd nem működik (kipróbáltam, hogy kizárjak minden mást).
De ez nekem érthetetlen. A boxon levő dtb/romnak elmékeim szerint semmi közének nem lehetne ehez és de.
Minden esetre most működik lehet futok egy pár kört a wifi élesztésével más rendszerek alatt.
Köszönet RedSwallow és yotco-nak a segítségért.[ Szerkesztve ]
-
blakey
titán
válasz kovakovi77 #58249 üzenetére
De ez nekem érthetetlen - Eltérő bootloader miatt lehetséges ez.
[ Szerkesztve ]
*** "Ne kérdezz többet, mint amennyi a hasznodra válik." - Dante *** "Csak akkor tehetsz meg mindent, ha már semmid sincs." - Harcosok klubja ***
-
szabi__memo
nagyúr
válasz kovakovi77 #58249 üzenetére
Szuper.
CE indítással kapcsolatban van valami fejlemény? -
szabi__memo
nagyúr
válasz kovakovi77 #58254 üzenetére
A zárt BL-es gondra gondoltam, valami olyan volt hogy CE nem indult csak az LE. De ha nemoldódott az jó
-
RedSwallow
tag
válasz kovakovi77 #58254 üzenetére
Transmission működik. SSH-val, telepíteni kell a csomagkezelőt:
# installentware
majd ez a leírás segít: https://github.com/RMerl/asuswrt-merlin/wiki/Installing-Transmission-through-Entware
A tűzfalas scriptet kihagytam, a web interface és a Kodi addon is szépen kezeli.
Ami még nem működik nálam, hogy box újraindítás után hibás könyvtárat ír a letöltött tartalomra, lehet csak lassan mountolja a hdd-t, de a transmission-daemon-t újraindítva megjavul:
# /opt/etc/init.d/S88transmission stop
# /opt/etc/init.d/S88transmission start -
kgymac
őstag
válasz kovakovi77 #58338 üzenetére
centos-en csatoltam így img-t (hdd raw mentés, 3 partícióval, a 3-at kellett csatolni, ext4), de meg kellett adni a filerendszer típusát is, hogy működjön.
-
Csicsóka
őstag
válasz kovakovi77 #58338 üzenetére
"De ha tudom a data particio kezdeti offset címét akkor ez működhet?"
Nekem nem működött, Oleg féle LE, 5.3.0-rc6 kernel. Z6 (S912 box)
Egyben látja az egész eMMC-t.LibreELEC:~ # cat /proc/partitions
major minor #blocks name
1 0 4096 ram0
1 1 4096 ram1
1 2 4096 ram2
1 3 4096 ram3
1 4 4096 ram4
1 5 4096 ram5
1 6 4096 ram6
1 7 4096 ram7
1 8 4096 ram8
1 9 4096 ram9
1 10 4096 ram10
1 11 4096 ram11
1 12 4096 ram12
1 13 4096 ram13
1 14 4096 ram14
1 15 4096 ram15
179 0 30535680 mmcblk1
8 0 7818152 sda
8 1 524288 sda1
8 2 7289768 sda2
7 0 91816 loop0VS CE:
root@CoreELEC-Z6:~# cat /proc/partitions
major minor #blocks name
7 0 158564 loop0
179 0 30535680 mmcblk0
179 1 4096 mmcblk0p1
179 2 65536 mmcblk0p2
179 3 524288 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 32768 mmcblk0p5
179 6 32768 mmcblk0p6
179 7 8192 mmcblk0p7
179 8 8192 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 32768 mmcblk0p10
179 11 524288 mmcblk0p11
179 12 32768 mmcblk0p12
179 13 1048576 mmcblk0p13
179 14 28049408 mmcblk0p14
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0Kilesve a CE alól az offset értéke...
[ 2.721553@0] mmcblk0: emmc:0001 SDW32G 29.1 GiB
[ 2.721709@0] mmcblk0boot0: emmc:0001 SDW32G partition 1 4.00 MiB
[ 2.721872@0] mmcblk0boot1: emmc:0001 SDW32G partition 2 4.00 MiB
[ 2.722028@0] mmcblk0rpmb: emmc:0001 SDW32G partition 3 4.00 MiB
[ 2.722856@1] mmcblk0: unknown partition table
[ 2.723585@0] [mmc_read_partition_tbl] mmc read partition OK!
[ 2.723586@0] add_emmc_partition
[ 2.723840@1] [mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000
[ 2.724025@0] [mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000
[ 2.724200@1] [mmcblk0p03] cache offset 0x000006c00000, size 0x000020000000
[ 2.724368@0] [mmcblk0p04] env offset 0x000027400000, size 0x000000800000
[ 2.724524@1] [mmcblk0p05] logo offset 0x000028400000, size 0x000002000000
[ 2.724686@0] [mmcblk0p06] recovery offset 0x00002ac00000, size 0x000002000000
[ 2.724855@1] [mmcblk0p07] rsv offset 0x00002d400000, size 0x000000800000
[ 2.725019@0] [mmcblk0p08] tee offset 0x00002e400000, size 0x000000800000
[ 2.725200@1] [mmcblk0p09] crypt offset 0x00002f400000, size 0x000002000000
[ 2.725361@0] [mmcblk0p10] misc offset 0x000031c00000, size 0x000002000000
[ 2.725533@1] [mmcblk0p11] instaboot offset 0x000034400000, size 0x000020000000
[ 2.725691@0] [mmcblk0p12] boot offset 0x000054c00000, size 0x000002000000
[ 2.725849@1] [mmcblk0p13] system offset 0x000057400000, size 0x000040000000
[ 2.726011@0] [mmcblk0p14] data offset 0x000097c00000, size 0x0006b0000000..se lehet mountolni.
Próbáltam a data, és cache-t nem jó.
Lementve LE alól dd-vel az egész mmcblk1-et image fájlba, úgy loop mountolva offset megadva, semmi eredmény.
CE alól kipróbálhatod, hátha. -
szabi__memo
nagyúr
válasz kovakovi77 #58395 üzenetére
Az oké hogy kiírod és onnan indul ahová teszed. De mi van ha több is van? (Tudom nem legyen) :-D
Pl sd vagy usb próbálnám miközben már hdd-ben van egy belakott rendszer...
Amúgy köszi -
kovakovi77
tag
válasz kovakovi77 #58434 üzenetére
A fentebb irt +0x400-as 1024 bytos rész csak nem igaz.
Valamit elnéztem most kipróbálom ujra.
Viszont Coreelec alatt az offset meg adás csak nem működik
Fáradt lehettem már este. -
kovakovi77
tag
válasz kovakovi77 #58436 üzenetére
Megoldva
Szóval CoreELEC 4.xx-kernelnél A95X MAX-on legalábbis
A cache,system,data felcsatolás szépen megoldható ha valaki esetleg ott akar duhajkodni
system-et nem ajánlom mert flashelés lehet a vége
Szóval a történet:
##############################################
# CoreELEC #
# https://coreelec.org #
##############################################
CoreELEC (official): nightly_20190906 (Amlogic-ng.arm)
CoreELEC:~ # mkdir /storage/cache
CoreELEC:~ # mkdir /storage/system
CoreELEC:~ # mkdir /storage/data
CoreELEC:~ # dmesg | grep mmcblk0
[ 1.082886@2] mmcblk0: emmc:0001 DF4064 58.2 GiB
[ 1.083026@2] mmcblk0boot0: emmc:0001 DF4064 partition 1 4.00 MiB
[ 1.083143@2] mmcblk0boot1: emmc:0001 DF4064 partition 2 4.00 MiB
[ 1.083255@2] mmcblk0rpmb: emmc:0001 DF4064 partition 3 4.00 MiB
[ 1.085587@2] meson-mmc: [mmcblk0p01] bootloader offset 0x000000000000, size 0x000000400000
[ 1.085601@2] meson-mmc: [mmcblk0p02] reserved offset 0x000002400000, size 0x000004000000
[ 1.085611@2] meson-mmc: [mmcblk0p03] cache offset 0x000006c00000, size 0x000046000000
[ 1.085704@2] meson-mmc: [mmcblk0p04] env offset 0x00004d400000, size 0x000000800000
[ 1.085716@2] meson-mmc: [mmcblk0p05] logo offset 0x00004e400000, size 0x000000800000
[ 1.085725@2] meson-mmc: [mmcblk0p06] recovery offset 0x00004f400000, size 0x000001800000
[ 1.085734@2] meson-mmc: [mmcblk0p07] misc offset 0x000051400000, size 0x000000800000
[ 1.085743@2] meson-mmc: [mmcblk0p08] dto offset 0x000052400000, size 0x000000800000
[ 1.085752@2] meson-mmc: [mmcblk0p09] cri_data offset 0x000053400000, size 0x000000800000
[ 1.085761@2] meson-mmc: [mmcblk0p10] param offset 0x000054400000, size 0x000001000000
[ 1.085770@2] meson-mmc: [mmcblk0p11] boot offset 0x000055c00000, size 0x000001000000
[ 1.085779@2] meson-mmc: [mmcblk0p12] rsv offset 0x000057400000, size 0x000001000000
[ 1.085797@2] meson-mmc: [mmcblk0p13] tee offset 0x000058c00000, size 0x000002000000
[ 1.085806@2] meson-mmc: [mmcblk0p14] vendor offset 0x00005b400000, size 0x000010000000
[ 1.085815@2] meson-mmc: [mmcblk0p15] odm offset 0x00006bc00000, size 0x000010000000
[ 1.085824@2] meson-mmc: [mmcblk0p16] system offset 0x00007c400000, size 0x000074000000
[ 1.085832@2] meson-mmc: [mmcblk0p17] data offset 0x0000f0c00000, size 0x000d9ec00000
CoreELEC:~ # losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 1 1 /dev/SYSTEM 0 512
CoreELEC:~ # printf "%d\n" 0x000006c00000
113246208
CoreELEC:~ # losetup -Pf -o 113246208 /dev/mmcblk0
CoreELEC:~ # mount /dev/loop1 /storage/cache
CoreELEC:~ # printf "%d\n" 0x00007c400000
2084569088
CoreELEC:~ # losetup -Pf -o 2084569088 /dev/mmcblk0
CoreELEC:~ # mount /dev/loop2 /storage/system/
CoreELEC:~ # printf "%d\n" 0x0000f0c00000
4039114752
CoreELEC:~ # losetup -Pf -o 4039114752 /dev/mmcblk0
CoreELEC:~ # mount /dev/loop3 /storage/data
CoreELEC:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1664168 189700 1474468 11% /dev
/dev/mmcblk1p1 524008 205888 318120 39% /flash
/dev/mmcblk1p2 6885613 133175 6748342 2% /storage
/dev/loop0 189952 189952 0 100% /
tmpfs 1922856 0 1922856 0% /dev/shm
tmpfs 1922856 8304 1914552 0% /run
tmpfs 1922856 0 1922856 0% /sys/fs/cgroup
tmpfs 1922856 16 1922840 0% /var
tmpfs 1922856 0 1922856 0% /tmp
/dev/loop1 1096072 1424 1066796 0% /storage/cache
/dev/loop2 1840980 1017300 807296 56% /storage/system
/dev/loop3 55968076 941464 54438960 2% /storage/data
CoreELEC:~ #Végén ajánlott lecsatolni
CoreELEC:/ # umount /dev/loop3
CoreELEC:/ # umount /dev/loop2
CoreELEC:/ # umount /dev/loop1
CoreELEC:/ # df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1664168 189700 1474468 11% /dev
/dev/mmcblk1p1 524008 205888 318120 39% /flash
/dev/mmcblk1p2 6885613 133176 6748341 2% /storage
/dev/loop0 189952 189952 0 100% /
tmpfs 1922856 0 1922856 0% /dev/shm
tmpfs 1922856 8304 1914552 0% /run
tmpfs 1922856 0 1922856 0% /sys/fs/cgroup
tmpfs 1922856 16 1922840 0% /var
tmpfs 1922856 0 1922856 0% /tmp[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58442 üzenetére
Na ez szuper eredmény!
Ezzel annyival vagyunk előrébb, hogy jól működik ez a megoldás. Annyi vele csak a probléma, hogy csak úgy lehet ezt a módszert használni, ha egyedi kernel image készül, amiben, az initrd alatt ez a felcsatolás megvalósul. Csak így, ha akkor már jelen van a data, tudja a CE init folyamat a /storage alá csatolni.
Ha minden boxnál egyforma lenne az eMMC partícionálása nem is lenne probléma, mert csak egy módosítás kellene az init szkriptbe. Ugyan azt még nem néztem meg, hogy az ott lévő busybox értelmező ismeri e a losetup utasítást, mert ha nem, akkor meg sem lehet oldani. Az én vasamon a cache offset pont annyi mint a tiédben, de a data már teljesen más 0x000097c00000 (system is) Ezért nincs általános, minden boxra jó megoldás.
Persze magadnak csinálhatsz egy ilyen spéci, eMMC-ről futó CE-t. A módosított kernel.img előállításában tudok segíteni.
Ja, még egy probléma ezzel. Ugrott a frissítés lehetősége, mert egyből felülírná a módosított kernel-t, és megint csak SD-ről futna.
-
Csicsóka
őstag
válasz kovakovi77 #58525 üzenetére
Igen, már lehet dmesg is kérni pld. A sed nekem sem egy igazán, de meglehetne oldani úgy, én is úgy gondolom.
S912 vason (csak ez van most) a koncepció működé képes. A cache-t tettem a /storage alá, az említett mount-storage.sh-val.
Tartalma:
losetup -Pf -o 113246208 /dev/mmcblk0
mount /dev/loop0 /storage
#debug_shellEredménye:
CoreELEC:~ # df -h
Filesystem Size Used Available Use% Mounted on
devtmpfs 1.2G 154.8M 1.1G 12% /dev
/dev/sda1 511.7M 169.6M 342.2M 33% /flash
/dev/loop0 487.9M 6.3M 445.8M 1% /storage
/dev/loop1 155.0M 155.0M 0 100% /
tmpfs 1.3G 0 1.3G 0% /dev/shm
tmpfs 1.3G 9.1M 1.3G 1% /run
tmpfs 1.3G 0 1.3G 0% /sys/fs/cgroup
tmpfs 1.3G 2.6M 1.3G 0% /var
tmpfs 1.3G 0 1.3G 0% /tmp
/dev/sda2 6.6G 8.3M 6.6G 0% /var/media/STORAGEdebug_shell sor elől a hesmark-t kivéve, initrd stádiumba marad, lehet parancsokat futtatni.
Tesztelésnél is kellett, mert első alkalommal indítva megállt a bootolás, a kodi indítása előtt közvetlen.
Új fájlrendszert kellett létrehozni a cache-be, mert nem tudott írni abba amit a droid maga után hagyott.Ezzel az aml_autoscript-el indítva nem lesz splash, és verbose módban indul. Teszteléshez kiváló.
-
junkpod
nagyúr
válasz kovakovi77 #58539 üzenetére
CoreELECx2:~ # df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1664168 189700 1474468 11% /dev
/dev/mmcblk1p1 524008 210120 313888 40% /flash
/dev/mmcblk1p2 14698664 609962 14084606 4% /storage
/dev/loop0 189952 189952 0 100% /
tmpfs 1922856 0 1922856 0% /dev/shm
tmpfs 1922856 8664 1914192 0% /run
tmpfs 1922856 0 1922856 0% /sys/fs/cgroup
tmpfs 1922856 2628 1920228 0% /var
tmpfs 1922856 0 1922856 0% /tmp
/dev/loop1 26064764 1508128 24507484 6% /storage/data_tesztBox's don't touch!
-
Csicsóka
őstag
válasz kovakovi77 #58548 üzenetére
Átnevezed aml_autoscript-re felülírod az eredetit vele, CE alól reboot update, és mennie kell.
/dev/loop0 igen mert abban az init fázisban még nem foglalt, és ugye az jön létre először.
Azátn már a loop1 a SYSTEM fájl lesz felcsatolva./dev/sda1 511.7M 169.6M 342.2M 33% /flash
/dev/loop0 487.9M 6.3M 445.8M 1% /storage
/dev/loop1 155.0M 155.0M 0 100% /Itt is látszik.
-
Csicsóka
őstag
válasz kovakovi77 #58553 üzenetére
Nem bántja csak a cahe-t, így csináltam én is, mert debug_shell-ben nincs mkfs, se mke2fs parancs, buta busybox miatt.
De megcsináltam megint, és ok, persze ez az én cache-em az ő adatai NAGYON fontosak valóban.
Remélem azt a 4-es kernel is így akarja, mert ugye én S912-n próbáltam.
Te nem tudod kipróbálni?CoreELEC (official): nightly_20190904 (Amlogic.arm)
root@CoreELEC-Z6:~# losetup -Pf -o 113246208 /dev/mmcblk0
root@CoreELEC-Z6:~# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 1 1 /dev/SYSTEM 0 512
/dev/loop1 0 113246208 0 0 /dev/mmcblk0 0 512
root@CoreELEC-Z6:~# mkfs.ext4 /dev/loop1
mke2fs 1.45.2 (27-May-2019)
/dev/loop1 contains a ext4 file system
last mounted on /storage on Tue Sep 10 20:40:50 2019
Proceed anyway? (y,N) y
Suggestion: Use Linux kernel >= 3.18 for improved stability of the metadata and journal checksum features.
Creating filesystem with 7606272 4k blocks and 1905008 inodes
Filesystem UUID: a376de4c-ce98-4ee2-bca4-73d70c4d419b
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done[ Szerkesztve ]
-
junkpod
nagyúr
válasz kovakovi77 #58550 üzenetére
Ez kell?
[ 3.995994@1] meson-mmc: [mmcblk0p03] cache offset 0x00
0006c00000, size 0x000046000000Box's don't touch!
-
Csicsóka
őstag
válasz kovakovi77 #58557 üzenetére
Meg a tiéd is ilyen.
[ 1.085611@2] meson-mmc: [mmcblk0p03] cache offset 0x000006c00000, size 0x000046000000
Lehet minden boxnál a cache itt indul.
Így semmit nem kell változtatni a példában írton, csak kipróbálni. -
Csicsóka
őstag
válasz kovakovi77 #58562 üzenetére
Akkor már ne állj meg itt, próba ezek szerint. Megtudjuk az igazságot S905x2-n is.
-
Csicsóka
őstag
válasz kovakovi77 #58564 üzenetére
Nálam nem sérült semmi, bentről fut az "éles" rendszerem.
-
kovakovi77
tag
válasz kovakovi77 #58566 üzenetére
Csak nem hagyott nyugodni a gondolat.
Ha te losetup -o xxxxxx loopX eszközt formáztál akkor neked is végig kellet menni és nagy tárhelynek kell lennie.
viszont erre is van megoldás losetup --help rész :
-o, --offset <num> start at offset <num> into file
--sizelimit <num> device is limited to <num> bytes of the file
Szóval megadhatjuk a tárhely max méretét is így biztos nem futunk bele másik partícióba.Jut fejembe losetupnal a -Pf helyett elvileg elég a -f
a -P akkor kellene ha ismert partíciós tábla tipussal ellátott img-filet kötünk be. esetünkben ez nem igaz.
-P, --partscan create a partitioned loop device[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58568 üzenetére
Nem lett nagy, fél giga, ahogy szokott is lenni a cache. Itt látható, ez a futó rendszerről van, a loop0 a cache. Lehetséges, hogy itt azért nem ment tovább, mert a dtb-ben megvannak a partíció méretek, és írtam, hogy ez 3-as kernel, 912-es box. Az biztos, hogy x2, és 922-nél meg kell majd adni hogy meddig szaladhat az mkfs.ext4.
-
kovakovi77
tag
válasz kovakovi77 #58580 üzenetére
És egyben én is átköltöztem bár én a rendszert későbbiekben majd ssd-ről bootolom.
CoreELEC (official): nightly_20190906 (Amlogic-ng.arm)
CoreELEC:~ # mount
devtmpfs on /dev type devtmpfs (rw,relatime,size=1664168k,nr_inodes=416042,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
/dev/mmcblk1p1 on /flash type vfat (ro,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop0 on /storage type ext4 (rw,relatime,data=ordered)
/dev/loop1 on / type squashfs (ro,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /var type tmpfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/mmcblk1p2 on /var/media/STORAGE type ext4 (rw,nosuid,nodev,noexec,noatime,data=ordered)Köszi Csicsóka a segítséget. Életemben nem találtam volna meg ezt a script-lehetőséget.
Így viszont ha a boot folyamatot eltudjuk kapni, akkor sok mást is lehet csinálni
Van is pár ötletem.[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58582 üzenetére
Na, akkor itt a bizonyíték, hogy megoldható x2 alatt is az eMMC ilyen jellegű használatára. Örülök hogy sikerült!
Ha nem veszem elő most az init szkriptet, nem találom meg ezt a /storage csatolós lehetőséget. Korább biztosan nem volt benne, mert elég sokat bújtam e témát az ext4 CE, és a **MC kapcsán. Nem is olvastam sehol, hogy a CE srácok ezt említették volna.Ezzel a megoldással, nem lehet bármit megtenni az init alatt, mert a folyamat egy adott pontján avatkozik be. Ez csak a /storage csatolása. Itt az említett rész az init-ből.
mount_storage() {
progress "Mounting storage"
if [ "$LIVE" = "yes" ]; then
# mount tmpfs and exit early. disk=xx is not allowed in live mode
mount -t tmpfs none /storage
return
fi
wakeonlan
if [ -n "$disk" ]; then
if [ -n "$OVERLAY" ]; then
OVERLAY_DIR=$(cat /sys/class/net/eth0/address | tr -d :)
mount_part "$disk" "/storage" "rw,noatime"
mkdir -p /storage/$OVERLAY_DIR
umount /storage
# split $disk into $target,$options so we can append $OVERLAY_DIR
options="${disk#*,}"
target="${disk%%,*}"
if [ "$options" = "$disk" ]; then
disk="$target/$OVERLAY_DIR"
else
disk="$target/$OVERLAY_DIR,$options"
fi
fi
if [ -f /flash/mount-storage.sh ]; then
. /flash/mount-storage.sh
else
mount_part "$disk" "/storage" "rw,noatime"
fi
else
# /storage should always be writable
mount -t tmpfs none /storage
fi
}Ha érdekel, az itt lesz az init és a platform_init szkript.
-
Csicsóka
őstag
válasz kovakovi77 #58600 üzenetére
Elvileg nem lehet baj a mount-storage.sh, mert nem dózeres szerkesztővel csinálta, nano meg jól kezeli a sorvégeket. Fájlrendszer hibára tippelek, ezért folytatva ott amit írtál, debug shell alatt lehet indítani fsck-t, hátha javít valamit, és elindul.
junkpod, ezt debug shell alatt próbáld, kell a boxra egy billentyűzet, angol kiosztás lesz.
e2fsck /dev/loop0
Ha javít valamit akkor ez volt a hiba, ha azt mondja hogy clean akkor:
losetup
dfmit mond?
reboot, poweroff debug módban is van.
-
junkpod
nagyúr
válasz kovakovi77 #58600 üzenetére
ez van a mount-storage.sh fileban (notepad++)
losetup -Pf -o 4016046080 /dev/mmcblk0
mount /dev/loop0 /storageCsicsoka: hát egy darab billentyűzet sincs a lakásban... majd holnap melóhelyről szerzek egyet.
esetleg más ötlet?
átneveztem a .sh fájlt, indult rendesen ahogy vártuk, és indult a frissítés is (found new .tar archive"... nem lehetséges, hogy a tar fájl jelenléte miatt máshogy indul a rendszer?
[ Szerkesztve ]
Box's don't touch!
-
Csicsóka
őstag
válasz kovakovi77 #58602 üzenetére
Ha nem rw-be csatolódott, akkor az rsync se tudott volna hiba nélkül lefutni.
Egy sync parancsot kellett volna még írnom, az rsync után, hogy kiürítse a pufferket, mert lehet hogy olyan gyorsan rebootolt, hogy valójában még írta a data-t. -
kovakovi77
tag
válasz kovakovi77 #58604 üzenetére
Esetleg még nevezd át a mount-storage.sh-t pld mount-storage.sh.bak.
Kártya a box-ba.
indít (régi rendszer simán elindul)losetup -Pf -o 4016046080 /dev/mmcblk0
e2fsck /dev/loop1y-ha kéri.
mount-storage.sh.bak - vissza nevez és próba 2.
(frissítést le vezényelheted a mai-ra, nekem frissítés után is rendben működik
CoreELEC (official): nightly_20190910 (Amlogic-ng.arm) -
kovakovi77
tag
válasz kovakovi77 #58608 üzenetére
Csicsóka tök ugyan ezt írta le. Csak gyorsabb volt XD
-
Csicsóka
őstag
válasz kovakovi77 #58613 üzenetére
Nálam van -P, és minden ok, cache, és data is működik, ahogy nálad is.
Kipróbálni persze kilehetne.
Belehet írni a végére egy losetupot, de ha nem verbose módban indít, nem fog látszani.[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #58678 üzenetére
Lehetne visszaszámolni 5,4,.. stb, de az rárondítana a szép spalsh képre, ami sokaknak fontos. intrd-ben nincs még IR kezelés, táv nem megy, billentyűzetet meg bedugni... Nem tetszene a népnek az tuti.
Ha van post-flash.sh akkor akár SMB-n lehet pillanat alatt átírni.
Új hozzászólás Aktív témák
- iOS alkalmazások
- Socket AM4
- PayPal
- Épített vízhűtés (nem kompakt) topic
- Samsung QN800D: Neo QLED 8K tévét teszteltünk
- Meggyőző arcjátékkal reagál a kínai humanoid robot
- Az Apple is mesterséges intelligenciával turbózza fel a teljes kínálatot
- Letartóztatták, mert AI segítségével csalt az egyetemi vizsgán
- 3D nyomtatás
- Mibe tegyem a megtakarításaimat?
- További aktív témák...
- Dell Optiplex 7040 - i7-6700, 16GB, 256GB, W10P
- ICERIVER KAS KS5M - 15TH - 3400W
- Gamer gép: i5 8500, RX 5600 XT 6GB, 2x8GB ram, HDD: 3TB, SSD: 120 GB, CM 600W, MSI Z390
- Gamer PC , i5 12400F , RTX 3060 12GB , 32GB 3200MHz , 512GB NVME , 2TB HDD
- Gamer PC , i7 8700 , RTX 3060 12GB , 32GB DDR4 , 512GB NVME , 1TB HDD
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen