-
Fototrend
OpenWrt topic
Új hozzászólás Aktív témák
-
Peter789
senior tag
továbbra se tudom, hogy az a 64K mi lehet, de ráhúztam a lengyel uboot-ot, utána vágtam a 64K konfigot ami a nevét, mac-et hozza, ráforrasztottam a nyákra és láss csodát:
*****************************************
* U-Boot 1.1.4 (Jun 19 2013) *
*****************************************
AP121 (AR9331) U-Boot for TL-MR3020
DRAM: 64 MB
FLASH: Winbond W25Q128 (16 MB)
LED on during eth initialization...
Hit any key to stop autobooting: 0
Booting image at: 0x9F020000...
Uncompressing kernel image...
## Error: failed to execute 'bootcmd'!
természetesen az openwrt még nem indul, hiszen 0x9F020000-től még csak egy rakás FF van...
-
Peter789
senior tag
az új uboot-ot már belesütöttem és úgytűnik vissza is olvassa hibátlanul, viszont elbizonytalanodtam a továbblépésen...
a 3020 AA squash factory miért csak 3840KB?
- uboot 64KB
- konfig 64KB
- kernel, rootfs, data 3840KB
- art 64KBde akkor itt még 64KB hiányzik... az hová kerül és mi a dolga?
-
Peter789
senior tag
C:\dev\SPIPGM>spipgmw /i
SPI FlashROM Programmer 2.13 (C) 2008-2013 by Martin Rehak; rayer@seznam.cz
Compiled by GCC 4.8.0 at 03:06:24, Jun 27 2013
(Win9x/NT/2K/XP compatability)
SPI connected to LPT port at I/O base address: 378h, SCK pulse width: t+0us
FlashROM JEDEC ID, type: EF4018h
Winbond W25Q128BV (16MB)
Status = 00h (SRP, AAI, BP3, BP2, BP1, BP0, WEL, BSY)
0 0 0 0 0 0 0 0eddig bíztató
-
-
Peter789
senior tag
válasz
vargalex
#1578
üzenetére
igen, azt az írásodat olvastam - a dupla flash-t támogató openwrt-nél némileg egyszerűbb megoldásnak tűnik az, ha csak a uboot-ig indítjuk a vasat és fizikailag kapcsolgatjuk a CS szálat a 2 párhuzamosított flash között. viszont az írásod rávilágított arra, hogy nem elég csak a kernel+fs és az art területet másolni, hanem a uboot utáni 64KB-ot is kell, ami a MAC-et és egyebeket tárolja...
a lengyel oldal szerint a Winbond W25Q128, ami a chipcad-nél is van olcsón az támogatott típus az oldalon lévő uboot részéről, és feltételezem akkor a teljes linux kernel is hozza magával a JEDEC ID-jét. olyat nem ír sehol, hogy az openwrt is további bűvészkedésekre szorulna, csak a uboot-ot említi mint problémás tényező...
egyébként lehet ha külső íróval kerülne át a 16 megás flash-be az eredeti uboot, konfig, kernel, fs és art partíció megfelelően pozícionálva, akkor ugyan a gyári uboot nem látná a flash méretét helyesen, de a kernel bútoláskor már mindent helyrerakna és tökéletes lenne úgy is?
-
Peter789
senior tag
szerencsére csak 8 ritka láb, az nem akkora mutatvány mint a memória csipp cseréje
ahogy nézem a WR703N kapcsrajzát, sajnos a CS lábon nincsen sehol egy soros ellenállás, úgyhogy egyből le kell majd venni a nyákról az ic-t, hogy párhuzamosítani lehessen a másikkal...
-
Peter789
senior tag
osztottam szoroztam, és arra jutottam hogy a 4 vagy 8MB flash kevés, de a 16MB-ban már nagy valószínűséggel elférne minden amire a projektemben szükségem van, így alaposan utánatúrtam a témának - az usb-s pendrive csak újabb fogyasztó és bizonytalansági tényező a rendszerben, és a boot is jóval gyorsabb a belső flash-ből, plussz kell neki egy port is - szerencsére mostmár sokkal részletesebb leírások is vannak, mint pár hónappal ezelőtt...
már lehet olcsón kapni megfelelő tokozású 128mbit-es flash-t: Winbond W25Q128FVSIG
a gyári tplink uboot sajnos buta, így azt le kell cserélni - ehhez már van készre fordított megoldás sokféle tp-link routerre: [link] [link] - valamint az ART partíciót is át kell mozgatni a gyári flash végéről az új flash végére, hogy működjön a wifi
a flash másolásához egyrészt lehetne ilyesmi USB-s SPI flash írót használni SO wide adapterrel - de egyszerűbb és olcsóbb megoldásnak tűnik helyette ez: [link] - mivel a uboot indulása után már nem olvas a flash-ből, így menet közben át lehet váltani fizikailag egy másik párhuzamosan kötött flash-re...
a folyamat soros konzolról:
- 4MB flash kiválaszt
- gyári uboot-ba indítás
- az utolsó 64KB ART partíció másolása RAM-ba
- 16MB flash kiválaszt
- flash terljes törlése
- ART kiírása a RAM-ból a flash-be
- TFTP-ről az új uboot behúzása a RAM-ba, majd kiírása a flash-be
- majd ugyanez az openwrt image-el isha nem rontom el a műveletek sorrendjét, akkor az eredeti flash érintetlen marad és akkor sincsen gond, ha valamit rosszul számolok és címzek a nagy flash-ben, bármikor újra lehet kezdeni
esetleg mást is érdekelne a téma? tudnátok segíteni végiggondolni, hogy jól pozícionálom e a címzéseket?
- az utolsó 64KB ART partíció másolása RAM-ba
a flash kezdete 0x9F000000, +4MB a vége az 0x9F400000, ebből minusz 64KB ami az ART mérete az 0x9F3F0000, vagyis:
cp.b 0x80800000 0x9F3F0000 0x10000- ART kiírása a RAM-ból a flash-be
a flash kezdete 0x9F000000, +16MB a vége az 0xA0000000, ebből minusz 64KB ami az ART mérete az 0x9FFF0000, vagyis:
cp.b 0x9FFF0000 0x80800000 0x10000- TFTP-ről az új uboot behúzása a RAM-ba, majd kiírása a flash-be
a 64KB-os uboot rögtön a flash elejére megy, tehát:
cp.b 0x9F000000 0x80800000 0x10000- majd ugyanez az openwrt image-el is
az image a flash eleje + 128KB-tól kezdődik:
cp.b 0x9F020000 0x80800000 0xHEXMÉRETa napokban megyek venni flash-t, akkor tudom a fenti elméletet a gyakorlatban is kipróbálni... egy apróság közben eszembe jutott, amire talán vargalex tud válaszolni: a kernel sdk-ban az mtd partíciók fix mérettel vannak definiálva, vagy automatikusan igazodik a max mérethez? vagyis jó lesz az alap AA owrt kernel, vagy abból is sajátot kell fordítani? feltételezem azt is írnák a fórumokon, ha nem igazodna...
-
Peter789
senior tag
válasz
attilav2
#1538
üzenetére
ha csak az a célod hogy ne villogjon, akkor a sötét szigetelőszalag a barátod!
az openwrt egy univerzális dolog, ami ennél fogva nem tud 100%-ig tökéletes lenni minden környezetben, de azért nagyon jól igyekszik... persze hogy a router gyártók specifikusra faragott szoftvere jobban kiszolgál pár feladatot, de ha kicsit is többre szeretnéd használni a vasat, akkor hamar korlátokba ütközöl > kell egy ilyen univerzális környezet... ha csak ismerkedni szeretnél vele, akkor vegyél ~6e-ért egy MR3220-as USB-s routert, dugj rá egy pendrive-ot extroot-al > ezt még nem nagy mutatvány összerakni, és innentől még ha sikerül totálisan meg is borítanod a rendszert, csak annyit kell tenned hogy lehúzod a meghajtót és úgy boot-olsz az eredeti alap környezetbe, majd letakarítva a pendrive-ot ismét elkezdesz építkezni (persze lehet róla menetközben biztonsági mentéseket is készíteni 1-1 nagyobb változtatás előtt)
-
#1525
Peter789
senior tag
fabiandaniel
#1523
Peter789
senior tag
válasz
fabiandaniel
#1523
üzenetére
lévén hogy a 4MB flash-ből ~800KB szabad, javaslom hogy kezdj egyből egy usb hub + pendrive-al: extroot
utána pedig minden azon múlik hogy mivel is akarsz még játszani - lehet guglizni mindenféle projekteket, blogokat hogy miket oldottak meg mások - ezekből tudsz ötleteket meríteni...
-
#1522
Peter789
senior tag
fabiandaniel
#1521
Peter789
senior tag
válasz
fabiandaniel
#1521
üzenetére
nekem is van egy v1.2 is - egyelőre még AA-RC1-el, nem frissítettem a véglegesre de ezzel is jól viselkedik...
-
#1442
Peter789
senior tag
Aeroglobus
#1440
Peter789
senior tag
válasz
Aeroglobus
#1440
üzenetére
a legtöbb mobilnetes sim-et nem lehet kívülről elérni, csak az üzleti fix IP címeseket - vagy a mobilnet csak esetleges opció és kábelen van?
-
#1438
Peter789
senior tag
Aeroglobus
#1437
Peter789
senior tag
válasz
Aeroglobus
#1437
üzenetére
ha nekiesel, akkor rá kell készülni: lsmod-al lementeni hogy per pill milyen modulokat használ pl a modem. ha kell neki usbmodeswitch, akkor annak is célszerű lementeni a kapcsoló fájlját, nehogy kiderüljön hogy nincsen benne az usbmodeswitch-data csomagban. van neted 3G nélkül is, vagy teljesen offline maradsz ha nekiesel?
-
#1432
Peter789
senior tag
Aeroglobus
#1430
Peter789
senior tag
válasz
Aeroglobus
#1430
üzenetére
ez a trunk r29756 elég öreg már - nem lehet hogy az okozza problémát hogy a régire ráhúztál mindenféle újabb verziós csomagokat és ott keveredett meg valami?
mindenestere azzal kezdeném, hogy a végleges AA-t vagy legújabb trunk firmwaret ráhúznám és úgy építeném fel a rendszert... nekem is van 3220-am is amit AA-val használok és atomstabil... régebben volt rajta trunk is, de azzal még mindenféle bajai voltak a wifinek - mostanára nyilván megoldották, de ha nem úttörő akarsz lenni, akkor inkább a stabil, többé már nem változó AA-t választanám...
-
Peter789
senior tag
válasz
szponzor
#1401
üzenetére
sajnos az openwrt toh wiki-n látható képén nem látszik végig a RAM felirata, de a részletekre rákeresve 8Mx16 szervezésű DDR1-nek tűnik és 66 lábú, mint az általunk is használt 64 megás csipp - csak a nagyobbaknak van pár kihasznált lába, ami a 16 megás alatt lehet egyáltalán nincs is bekötve - össze kell hasonlítani pár adatlapot, kikeresni a különbségeket és megpróbálni megnézni a nyákon, hogy van e azon a lábon vezeték - ha van, akkor esélyes hogy végrehajtható a tuning... illetve első körben guglizni kell, hogy valaki csinált e már ilyet - mindenesetre a wiki-n nem írnak se pro, se kontra semmit - ami elég furcsa...
-
Peter789
senior tag
-
Peter789
senior tag
válasz
ZeUS2140
#1355
üzenetére
úgynézem ugyanaz a 16Mx16 = 32MB csipp van az 1043-on is, tehát ehhez is ugyanolyan kell mint a 3020/3220/3420-hoz... sokat számít a plussz ram ha extra dolgokra akarja használni az ember - alapból szűk 10 mega szabad ami nagyon hamar elfogy, ha elindítunk rajta pár perl script-et, transmission-t, stb...
-
Peter789
senior tag
válasz
ZeUS2140
#1353
üzenetére
66 lábú TSSOP tokozású 400MHz-es CL3-as 32Mx16bit szervezésű DDR1 csipp kell neki > cirka bármelyik fél gigás noti DDR1 modulról le lehet bontani amin 8 db ilyen csipp van. Az asztali DDR1 modulok nem jók hiába lenne 64MB-os egy csipp rajta, mert azok mind 128Mx4bit vagy 64Mx8bit belső felépítéssel rendelkeznek. A legtöbb 333MHz-es is jó, ha azt CL2.5-el tudja - én is ilyet bontottam szét...
a bontáshoz mezei párezres hőlégfúvót használok - max fokozaton határozott mozdulatokkal körözve a csipp felett hamar lejön - egy pengével finoman megfeszítem a szélét, nem erőltetve nehogy feltépje a nyákpadot. amikor mindkettő lejött, akkor ónszívó rézszövettel és folyasztószerrel letisztítom a lábakat és a padokat is, majd celluxal pozícióba rögzítem a csippet és kevés forrasztópasztát használva körbejárom a lábakat lapos fejű weller pákával. végül többször átnézem nagyítóval, nehogy valahol átkötés maradjon a lábak között...
eddig egy routert sem tettem tönkre, de azért van némi veszélye a dolognak
szerk: mondjuk mostanra már elég megfizethető a 128 mega ramos WDR3500 is, egyre kevesebb értelme van az ilyen bűvészkedésnek, de azért jól jöhet itt-ott... igazából a legjobb az lenne ha valahol lehetne ezt is darabra venni - állítólag egy az egyben firmware kompatibilis a WR703N / MR3020 -al - most így hirtelen nem akarok 1000 darabot rendelni belőle még akkor se, ha ilyen olcsó
-
Peter789
senior tag
-
Peter789
senior tag
ismét lesújtott a hőlégfúvóm, ezúttal egy MR3020 az áldozat:
root@OpenWrt:~# dmesg
[ 0.000000] Linux version 3.3.8 (blogic@Debian-60-squeeze-64-minimal) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Sat Mar 23 16:49:30 UTC 2013
[ 0.000000] MyLoader: sysp=444ba8b5, boardp=5fbcaeef, parts=ebc66edc
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU revision is: 00019374 (MIPS 24Kc)
[ 0.000000] SoC: Atheros AR9330 rev 1
[ 0.000000] Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:25.000MHz
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 04000000 @ 00000000 (usable)
...
[ 0.000000] Kernel command line: board=TL-MR3020 console=ttyATH0,115200 rootfstype=squashfs,jffs2 noinitrd
...
[ 0.000000] Memory: 61488k/65536k available (2211k kernel code, 4048k reserved, 418k data, 212k init, 0k highmem)
...root@OpenWrt:~# free -m
total used free shared buffers
Mem: 61700 20764 40936 0 1972
-/+ buffers: 18792 42908
Swap: 0 0 0egy MR3220 és egy MR3420 már hosszú ideje sikeresen teljesít a tuning után, remélem az MR3020 is stabilnak bizonyul...
-
#1256
Peter789
senior tag
kisgyerek85
#1255
Peter789
senior tag
válasz
kisgyerek85
#1255
üzenetére
a toh wiki oldalakon sokszor lassan megy utána az infó a valós állapotoknak, érdemes mindig turkálni a könyvtárak között hogy van e változás - az RC1 óta már kijött az RC2 és abból lett a végleges AA - köztük pedig eltelt 5 hónap
-
#1254
Peter789
senior tag
kisgyerek85
#1253
Peter789
senior tag
válasz
kisgyerek85
#1253
üzenetére
miért akarod az AA RC1-et? akkor már miért nem a végleges AA-t? az fs típusokból a squash a javasolt, azon belül pedig a gyári fw-ről átállásra a factory kell neked [link] - lehet ilyen fájlnéven nem fogja megenni > akkor nézd meg hogy a gyári fw-nek mi a neve és nevezd át arra a bin-t
-
#1252
Peter789
senior tag
Aeroglobus
#1250
Peter789
senior tag
válasz
Aeroglobus
#1250
üzenetére
ismerősnél és nálam is az oldotta meg a modem stabilitási problémát, hogy a rádugott USB HUB-ba raktunk egy nagyobb elkót (1000uF+ vagy amekkora csak elfér)
-
Peter789
senior tag
-
Peter789
senior tag
válasz
szponzor
#1232
üzenetére
nem tudom hol találtál olyan régit, de a trunk pár naponta frissül és a végleges attitude adjustment is alig másfél hónapos...
a squash picit pazarlóbb, de praktikusabb úgyhogy az a javasolt - ha sok hely kell, akkor úgyis extroot-ot kell rakni egy pendrive / usb-s vinyóra
-
Peter789
senior tag
Sziasztok ismét!
A projektem újabb szakaszához értem: mivel offline lesz az eszköz, ezért jó volna, ha tudná mennyi a valós idő. Viszont az MR3020-on lévő AR9331-nek nincsen RTC modulja (vagy csak nincsen fizikailag bekötve és aktiválva a platformban?). A lényeg hogy külső RTC kell neki, ezért mivel találtam jópár leírást, hogy pl raspi-hoz hogyan kell illeszteni a kész kernel modulokkal a DS1307-et, ezért beszereztem egy ilyen IC-t és köréraktam amit még kér, majd rákötöttem a 3G/WISP/AP gombok 2 GPIO-jára - kézenfekvő, mert AP módban fel van húzva mindkettő a nyákon, így még azzal sem kell törődni. az i2c-gpio-custom kernel modullal I2C buszt csináltam belőlük, és már látja is a DS1307-et a 0x68 címen:
i2cdetect -y i2c-gpio0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --az engedélyező bit átállítása után pedig számolja is az időt
i2cdump -y i2c-gpio0 0x68 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 40 03 01 01 01 01 00 03 00 00 00 00 00 00 00 00 @?????.?........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Tovább viszont nem jutok... Akárhogy túrom az AA forrását, nem találok benne semmiféle RTC támogatást... az openwrt-ből ezt totál kihagyták? Próbáltam az others.mk-ba lemásolva egy eeprom szekcióját hozzáadni, meg is jelenik a menuconfig-ban, de hiába választom ki, fordítás után nem találok ilyen .ko-t vagy .ipk-t...
Valaki esetleg próbálkozott már ilyennel? Vagy bármi hasonló, az .mk fájlokban alapból nem létező eszköz élesztésével? Tulajdonképpen egy mezei perl/shellscript programmal meg tudnám oldani, hogy indulásnál az i2cget segítségével kiolvassa és beállítsa róla az időt, de jobban örülnék ha mindezt a kernel natív megoldása kezelné a hwclock-al...
-
Peter789
senior tag
válasz
vargalex
#1188
üzenetére
még az is lehet hogy az előző rebút előtt nem akart rendesen leállni a vsftpd, de előtte mindkettőt beengedte és mindkettő turkálhatott a root-ban is, os újraindulás után viszont helyére ugrott az allowed lista és már csak a root-ba jutás rész maradt, amit a chroot-os sorok beiktatása és a vsftpd újraindítása egyből helyre is tett...
-
Peter789
senior tag
válasz
vargalex
#1186
üzenetére
köszönöm, áttételesen rávilágítottál a problémára: ugyan nem a vsftpd nem állt le rendesen, de úgy tűnik, hogy hiába hoztam létre a passwd-ben a usert, amíg nem indítottam újra az os-t addig egyszerűen nem akarta az allowed listából felolvasni - ezért maradt a root, viszont ami fura hogy loginnál már megette az ftp_1 useremet is, szóval beengedte mindkettőt, nem érvényesült az allowed lista... vannak fura dolgok, de a lényeg hogy mint windows-nál, ha nem akar valami működni akkor minden ablak bezár és reboot
-
Peter789
senior tag
válasz
vargalex
#1184
üzenetére
köszi a segítséget, de valahogy még így sem jó...
userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd.allowedugyanúgy kiengedi a home-ból a usert, csak írni nem tud máshová, mint a sajátja... és ettől sem változik semmi a viselkedésében:
chroot_local_user=NO
chroot_list_enable=NOnekem arra lenne szükségem, hogy kizárólag az ftp usert engedje be csak a home-jába, a root-ot pedig egyáltalán ne...
(természetesen újraindítom a vsftpd-t minden változtatás után)
-
Peter789
senior tag
viszont most a vsftpd-vel kapcsolatban kérném a segítségeteket, mert nagyon nem tudok vele megoldásra jutni... azt szeretném összehozni, hogy kizárólag egy dedikált ftp user férjen hozzá, és az is lehetőleg csak a megadott home könyvtárához...
létrehoztam egy usert
ftp_1:x:1001:2000:ftp_1:/home/ftp_1:/bin/false
adtam nek jelszót, majd szerkesztettem a vsftpd konfigját:
root@OpenWrt:/etc# cat vsftpd.conf
background=YES
listen=YES
listen_port=xxxx
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
check_shell=NO
session_support=NOha ehhez még ennyit adok, akkor beengedi a root és ftp_1 usert is, utóbbinak persze csak a home-jába van joga írni, de nézelődni bármerre tud a /-ben:
ftp_username=ftp_1
ha ezt írom bele, akkor viszont a root-ot beengedi, az ftp_1 usert viszont nem...
userlist_enable=YES
userlist_file=/etc/vsftpd.allowedroot@OpenWrt:/etc# cat /etc/vsftpd.allowed
ftp_1mit rontok el?
-
Peter789
senior tag
válasz
Peter789
#1167
üzenetére
sikerült is éleszteni, ennyi:
nálam a card 0 az usb-s hangkártya - jelenleg csak ez az egy van rádugva...
root@OpenWrt:/# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Set [C-Media USB Headphone Set], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0létre kell hozni a köv fájlt, nálam hw:0 eszközre mutatva, a cmedia az tetszőleges címke. a buffer a töredéke volt, nálam eddig kellett emelni hogy már ne recsegjen, zizegjen néha... mivel samplerate konvertálás per pill nincsen konfigolva, így csak olyan anyagot lehet ráküldeni ami itt be lett állítva - itt 48KHz. a bindings-el lehet rámutatni hogy az X fizikai csatorna közül melyik(ek)en szólaljon meg az adott slave eszköz
root@OpenWrt:~# cat .asoundrc
pcm_slave.cmedia {
pcm "hw:0"
channels 2
rate 48000
buffer_size 16384
period_size 8192
periods 0
period_time 0
}pcm.ch0 {
type dshare
ipc_key 5678293
slave cmedia
bindings.0 0
}pcm.ch1 {
type dshare
ipc_key 5678293
slave cmedia
bindings.0 1
}az ipc_key nem tudom pontosan mire van, de én itt találtam meg az értékét:
root@OpenWrt:/etc# cat /usr/share/alsa/alsa.conf | grep ipc_key
defaults.pcm.ipc_key 5678293majd tetszőleges alsa-s lejátszóval lehet hivatkozni a virtuális eszközre...
aplay -D ch0 /usr/share/sounds/alsa/Front_Left.wav
-
Peter789
senior tag
válasz
vargalex
#1138
üzenetére
elfelejtettem megerősíteni hogy igen, ez volt a megoldás, DHCP-re kellett rakni... thx
tudom hogy szervesen nem kötődik az openwrt-hez, de mivel ezen használnám, így rákérdezek: ALSA-n keresztül pl az aplay vagy más progi használatával meg lehet oldani, hogy egy wav a hangkártya tetszőleges csatornáján szólaljon meg? és persze párhuzamosan egymástól eltérő időben el lehessen érni másik csatornáját is ugyanígy. szimpla mono hangokat szeretnék megszólaltatni jópár csatornán párhuzamosan / eltolva, lehetőleg minél kevesebb USB-s hangkártya felfűzésével - első körben pár sztereót dugnék rá, de hosszútávon akár egy valós 5.1-7.1-es cmedia CM6206/LX-el egyetlen USB eszközzel is megoldható lenne?
ilyenben van valakinek gyakorlati tapasztalata?
-
Peter789
senior tag
válasz
vargalex
#1146
üzenetére
azt írja hogy már van virtuális soros eszköze, tehát túlvan a modeswitch-en
sajnos az adott típussal nincsen gyakorlati tapasztalatom, mert nekem olyan modem kellett ami független, de azt meg tudom erősíteni hogy ahány modem, annyi féle nyűggel lehet találkozni... 7-8 féléből talán 2 volt olyan ami probléma nélkül első pöccre beüzemelhető volt, és pár olyan is akadt amivel fel is adtam, egyszerűen nem tudtam rájönni a csatlakozás nyitjára...
-
#1145
Peter789
senior tag
cementelek
#1144
Peter789
senior tag
válasz
cementelek
#1144
üzenetére
nem egy modemmel akadtam el én is a tárcsázásnál... ami chatscript / AT parancssor tökéletesen működött win vagy ubi alól, az az openwrt-n nem akart menni...
a végén úgy meguntam a szenvedést a mindenféle stick-ekkel (próbáltam USB-re kötött option GTM-378, 380 mini PCIe-s modemekkel is), hogy terveztem egy kis EVB nyákot a SIM5320E modulhoz, és azóta is ezeket használom a legnagyobb megelégedéssel. tény hogy nem egy sebességbajnok, viszont a problémamentes openwrt-s működése, a LUA script nyelv támogatása és az integrált GPS funkció bőven kárpótol...
-
#1142
Peter789
senior tag
cementelek
#1141
Peter789
senior tag
válasz
cementelek
#1141
üzenetére
első körben egy asztali linuxos környezetben szoktam megnézni az ilyen eszközöket, hogy milyen kernel modulokat használ. ha win-ed van, akkor pl egy vmware-be lehet felhúzni egy ubuntu-t, annak átadni az usb-s eszközt. ha felismeri és képes végrehajtani a modeswitch-et (dmesg-ben először csak 1-2 mass storage eszköz jelenik meg, majd ha átvált akkor jönnek a virtuális sorosportok is), akkor kiderül hogy az lsmod által visszaadott betöltött kernel modulok listája hogyan bővül. ha alapból nem megy a modeswitch, akkor a modem nevére, vagy a vendor id / product id-re + usb modeswitch kulcsszavakra guglizva meg kell próbálni kitúrni a megfelelő parancssort, ha valaki már publikálta...
(első körben ezek általában mint meghajtók látszanak, ahonnan a win-es drivert telepítheted. az usb modeswitch parancs böki át modem módba - ha felismeri)
-
Peter789
senior tag
megnéztem a cisco EPC3925 kábelmodem connected devices listájában:
amíg csak a 3020 van rádugva a WAN-ra, de wifivel nem csatlakozik hozzá senki, addig 192.168.0.17 címet oszt ki neki. megpróbáltam kinyitni a WAN felől a tűzfalat:
#open ssh on wan interface
config rule
option src wan
option dest_port 22
option target ACCEPT
option proto tcpde így se tudok hozzá csatlakozni...
ha wifivel rálépek, akkor a gép a 192.168.0.16-os címet kapja, a 17 pedig eltűnik idővel a listából... valaki valami tipp?
-
Peter789
senior tag
sziasztok ismét!
játék célra vettem egy MR3020-ast, rá is húztam egyből a legutóbbi AA r36088-at, viszont egy furcsa jelenségbe futottam...
- ha LAN kábelen csatlakozok rá, akkor elérem a luci-t és az ssh-t is a 192.168.1.1 címen
- ha kábel csatlakoztatása nélkül bútol és wifin csatlakozok rá, akkor szintén elérem ezeket a fenti címeken
- viszont ha megkapja a WAN-t, akkor onnantól wifire 192.168.0.* címet oszt ki, a 192.168.0.1-re a kábelmodem kerül, és sehol nem találom magát a routert, egyszerűen transzparenssé válik...hogyan tudnék rácsatlakozni a luci-ra és ssh-ra a WAN mellett? a wifi ugyanúgy AP módban van, mint az MR3220-nál, ahol a csatlakoztatott WAN mellett wifi felől is rá tudok csatlakozni a felületeire...
-
Peter789
senior tag
válasz
Peter789
#1106
üzenetére
turkáltam a minicom menüjében, és kiderült hogy hiányzik a /usr/bin/sx és /usr/bin/rx, amit az lrzsz csomaggal helyre is raktam - érdekes hogy hibaüzenetet nem adott a minicom nélküle... most picit más a kép, ugyanaz mint ubuntu-n:
┌───────────[xmodem upload - Press CTRL-C to quit]────────────┐
│Sending hb12.lua, 4 blocks: Give your local XMODEM receive co│
│mmand now. │
│Xmodem sectors/kbytes sent: 0/ 0kRetry 0: Got 00 for sector│
│ ACK │
│Retry 0: Timeout on sector ACK │
│Retry 0: Timeout on sector ACK │
│ │
└─────────────────────────────────────────────────────────────┘és így sem történik semmi...
-
Peter789
senior tag
bár csak részben kötődik az openwrt-hez, de azért közeli téma, hátha tud valaki segíteni...
szóval adott egy SIM5320E modem modul, amire LUA programot szeretnék feltölteni. USB-n csatlakozik az usbserial és option driver csomaggal, és 5 virtuális portot telepít fel: diag, NMEA(GPS), AT, modem, wireless eth
win alól hyperterminallal működik simán: kiadom az AT+CRXFILE="localfile" parancsot az AT portra, majd a menüből XMODEM protokollal ráküldöm a script fájlt, és utána lehet indítani. de amikor ugyanezt végigjátszom openwrt alól minicom-ból, akkor vár, vár, vár a fájlra majd idővel timeout-ba fut - mintha nem kapna semmit a minicom-tól, hiába nyomok OK-ot a küldésre...
valami konfig / plugin még hiányozhat a minicom-nak, vagy mi lehet a hasfájása szerintetek?
-
#1101
Peter789
senior tag
Speeedfire
#1100
Peter789
senior tag
válasz
Speeedfire
#1100
üzenetére
jah most néztem meg mi is ez... lehet akkor a memóriából fut ki nálad? ahogy írtam, nekem rettentő sok memóriát benyel...
-
#1098
Peter789
senior tag
Speeedfire
#1097
Peter789
senior tag
válasz
Speeedfire
#1097
üzenetére
régi vagy alsa módban próbáltad? nekem a ramot is nagyon eszi az mpd, a 64 megásra tuningolt 3220-on 20-30 megát benyelt magának, de alsa-val így megy stabilan, akadásmentesen mindenféle rádió stream-el...
-
#1072
Peter789
senior tag
csocsika1700
#1069
Peter789
senior tag
válasz
csocsika1700
#1069
üzenetére
talán találtak valami fatális védelmi hibát, és azért szedték le teljesen a verzió support-ját. ráadásul 3420-at egyáltalán nem is látok a dd-wrt támogatott eszközök listáján, szóval valószínűleg valami beta állapotban lehetett az egész...
ha v1 tégla forma a hardver, akkor mehet rá az attitude adjustment rc1 r34185 openwrt:
http://downloads.openwrt.org/attitude_adjustment/12.09-rc1/ar71xx/generic/
ez 2012 novemberi stabil verzió, nem valószínű hogy csak úgy eltüntetnék bármikorha v2 ufó forma akkor csak a trunk jöhet szóba:
http://downloads.openwrt.org/snapshots/trunk/ar71xx/
ez viszont napról napra változhatezt nem tőled kérdezem hanem a guruktól: mi van akkor ha változik a kernel verzió a kernel modulok csomagjaiban? a kicsi kernel* nevű csomag megmondja neki hogy mi változott és fog működni 1-2 év múlva is minden trunk-os update a jelenlegi image-el is, nem kell újra flash-elni?
(#1070) King Unique
a fenti linkeken Te is megtalálod a hw verziódhoz illő squashfs factory image-eket, de ha fizikailag gyengélkedik az a hardver, akkor első körben lehet inkább egy garanciális cserével próbálkoznék be...
-
#1003
Peter789
senior tag
katalin888
#1001
Peter789
senior tag
válasz
katalin888
#1001
üzenetére
szia!
az openwrt mire kellene? ha csak okosított tűzfal és jobb személyreszabhatóság miatt, akkor akár egy 4-5e-es TL-WR740N / 741ND is jó lehet neked, ha kapsz olyan hw verziót ami támogatott
ha szeretnél USB-t is hogy extra programok is elférjenek, akár torrent, ftp vagy más felhasználásra, akkor a 6-7e-es TL-MR3020 vagy 3220, esetleg picit drágábban a dupla antennás 3420-as
számottevően nagyobb tudásért már rendesen zsebbe kell nyúlni, a TL-WDR3600 és 4300 ~15-20e-től vannak - bár itt már a proci is jóval erősebb, 4x annyi a memória, erősebb a wifi, szóval nem pénzkidobás ha ki is tudod használni...
-
Peter789
senior tag
válasz
vargalex
#976
üzenetére
pedig határozottan úgy rémlik - pár napja csináltam azt is, nem olyan régen - hogy nem kellett elindítani a uhttpd-t hozzá, egyszerűen "opkg install luci" és már ment is...
viszont a hidraw-al egyszerűen nem bírok megoldásra jutni... az AA_beta-hoz ez alapján simán meg tudtam csinálni: #11145 new enhancement: Support special HID devices (hidraw support)
most az új trunk package/kernel/modules/other.mk -ban már nincsen sehol a hid.ko-s rész, viszont az input.mk-ban megtaláltam. ugyanolyan formában, mint régen. ugyanúgy beleírtam a konfig sorba:
KCONFIG:=CONFIG_HID CONFIG_HIDRAW=yfordítás után a .config-ba bele is került az opció:
mips@ubuntu:~/trunk/build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/linux-3.7.9$ cat .config | grep HID
# HID support
CONFIG_HID=m
CONFIG_HIDRAW=ya fordított kernel modul pár KB-al nagyobb is lett mint előtte, viszont hiába csatlakoztatom a hidraw eszközt (USB-s PIC24 mikre HID könyvtárral, illetve egy CM108-as USB-s hangkártya GPIO lábai is így látszanak - az AA_beta módosított hid.ko-val ment mindkettő), nem jelenik meg a /dev-ben az eszköz és a dmesg-ben a csatlakoztatására is csak ennyit dob:
[ 159.030000] usb 1-1.4: new full-speed USB device number 5 using ehci-platform
[ 163.910000] usb 1-1.4: USB disconnect, device number 5
[ 164.160000] usb 1-1.4: new full-speed USB device number 6 using ehci-platformvan valami tipped hogy miért nem működik, mit kéne másképp csinálni ennél az új kernelnél?
-
Peter789
senior tag
válasz
Peter789
#973
üzenetére
most jött ki a r35838 trunk, úgyhogy végül azt húztam rá. egy apró hiba, ami megszivatott kicsit: a luci hiába rakja fel a uhttpd-t, nem indul el alapból, kézzel kell enabled-re állítani hogy ne kelljen minden újraindulás után ssh-ról indítgatni... érdekes módon a r35754-el nem volt ilyen gondom, egyből elérhető volt a luci telepítés után, viszont ott meg ugye a wifi volt döglött...
-
Peter789
senior tag
felhúztam a 3220-ra a legújabb trunk-ot (r35754 helyett r35819) és itt már alapból a helyén volt az /etc/config/wireless, amiben elég volt csak #-olni a disabled sort és már megy is tökéletesen a wifi dmesg hibaüzenetek nélkül. úgylátszik pechesen belenyúltam a barrier breaker hibás szériájába, ha pár nappal később lépem meg a frissítési próbát akkor már nem is látom a hibát...
most akkor ismét nekifutok a hidraw témának, hátha itt már az is összejön...
-
-
Peter789
senior tag
válasz
vargalex
#949
üzenetére
melyiket próbáltad? én még a 35754-et, de ahogy nézem mostmár a 35770 van a trunk-ban
más érdekes problémám is adódott: előbbre írtam, hogy az alapból hiányzó HIDRAW támogatást sikerült hozzáadnom a beta-hoz > az other.mk-hoz kellett hozzáadni a megfelelő HID szakaszba a CONFIG_HIDRAW=y -t és újrafordítani. itt úgytűnik hogy átköltözött a HID az input.mk-ba. ugyanahhoz a szakaszhoz hozzáadom ugyanúgy mint a régebbi kernel esetén, de ez a verzió egyszerűen nem akarja megenni akkor sem a HIDRAW eszközöket...
-
Peter789
senior tag
ha csak helyhiányod van, akkor miért nem teszel alá egy pendrive-os extroot-ot ? onnantól korlátlan szabad helyed lesz mindenféle csomagoknak, programoknak...
a jelen trunk-al nekem gondom van, az MR3220-assal nem megy a wifi, és mint a lentebb linkelt patch mutatja, az 1043-al se megy alapból, bár azt állítólag javítja a patch-el újrafordított kernel modul, az MR3220-on viszont nem segített egyelőre
egyébként egyszerű alá behúzni a luci-t, csak package-ként telepíteni kell ssh-val és kész, de utána lehetnek még hiányzó beállítások
-
Peter789
senior tag
ezt találtam rá: WiFi died at 1043ND (with r35754 build)
a fix által hivatkozott net/mac80211/main.c -t 3 helyen is megtaláltam a trunk-on belül:
./build_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/linux-3.7.9/net/mac80211/main.c
./build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2013-02-22/net/mac80211/main.c
./build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/linux-3.7.9/net/mac80211/main.caz elsőben és a harmadikban sehol nincsen CONFIG_IPV6, csak CONFIG_INET - ezek elé beraktam a __disabled__-et. a másodikban pedig ott volt mindkettő, és már "gyárilag" ott van a __disabled__ mindegyik előtt... újraforgatás után egyesével bemásoltam a keletkező kernel modulokat a helyére, és mind ugyanúgy hatott rá: kevesebb a hiba, de még mindig nem megy a wifi...
ennyi az egész vonatkozó dmesg szakasz:
[ 33.040000] Compat-drivers backport release: compat-drivers-2013-01-21-1
[ 33.050000] Backport based on wireless-testing.git master-2013-02-22
[ 33.050000] compat.git: wireless-testing.git
[ 33.090000] cfg80211: Calling CRDA to update world regulatory domain
[ 33.090000] cfg80211: World regulatory domain updated:
[ 33.100000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 33.110000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 33.110000] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 33.120000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 33.130000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 33.140000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 33.670000] ath9k: Unknown symbol relay_open (err 0)
[ 33.680000] ath9k: Unknown symbol relay_close (err 0)
[ 33.680000] ath9k: Unknown symbol relay_switch_subbuf (err 0)
[ 33.690000] ath9k: Unknown symbol relay_file_operations (err 0)vargalex Te még nem használod ezt a legújabb trunk-ot? mint a patch mutatja, nem csak a 3220-asnál áll fent ez a probléma, bár elvileg az 1043-on megoldotta a patch ha minden igaz, nálam meg nem...
-
Peter789
senior tag
sziasztok ismét!
ráhúztam a legújabb trunk-ot a 3220-asra, de sehogy nem tudom éleszteni a wifi-t. nincsen /etc/config/wireless. megpróbáltam az előző beta-ról készült biztonsági másolatból bemásolni, de nem hatja meg, azt mondja hogy "Wireless is disabled or not associated". dmesg-ben látszik hogy valami wifi féle éledezik:
[ 34.700000] Compat-drivers backport release: compat-drivers-2013-01-21-1
[ 34.710000] Backport based on wireless-testing.git master-2013-02-22
[ 34.720000] compat.git: wireless-testing.git
[ 34.750000] cfg80211: Calling CRDA to update world regulatory domain
[ 34.760000] cfg80211: World regulatory domain updated:
[ 34.770000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 34.770000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 34.780000] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 34.790000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 34.800000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 34.810000] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 35.220000] mac80211: Unknown symbol unregister_inet6addr_notifier (err 0)
[ 35.220000] mac80211: Unknown symbol register_inet6addr_notifier (err 0)
[ 35.550000] ath9k: Unknown symbol ieee80211_start_tx_ba_cb_irqsafe (err 0)
[ 35.560000] ath9k: Unknown symbol relay_open (err 0)
[ 35.560000] ath9k: Unknown symbol ieee80211_free_hw (err 0)
...ezekből az unknown symbol sorokból van még szép számmal, ez normális? rémlik mintha a beta alatt is ilyesmi lett volna, de nem mernék rá mérget venni...
összehasonlítottam a csomaglistát is a régivel, ez az egy hiányzott amit a wifi témához tudok kötni: wireless-tools - felraktam, semmi változás...
mi hiányzik még neki hogy menjen?
-
Peter789
senior tag
van pár lehetőséged:
1. mmc-over-gpio - SD kártya illesztése szoftveresen GPIO lábakra. leírásokat kell vadásznod arra, hogy az adott alaplapon pl a LED-ek melyik GPIO-kat foglalják, azokból fel kell szabadítani 4-et és mehet rá egy SD foglalat. a sebessége nem az igazi és bár nincsen vele gyakorlati tapasztalatom, de a hibamentességében / megbízhatóságában sem bíznék annyira - ebben lehet valaki megcáfol majd
2. egyrészt le lehet cserélni az SPI flash-t nagyobbra (a 4 megásat 8, esetleg 16 megásra), vagy az SPI flash mellé lehet varrni egy plusz SD kártyát, de mindkettő kernel módosítást és újrafordítást igényel, nem kis mutatvány
3. elvileg az alaplapi, be nem forrasztott USB port is éleszthető, akkor dughatsz rá HUB-ot, pendrive-ot, bármit ami csak tetszik, viszont sok a verzió, erre konkrét leírást és tapasztalatokat kell keresni mielőtt nekiesel. a pendrive-ra mehet az ext-rootfs, és annyi gigád lesz amennyit csak akarsz
4. veszel egy MR3020 / MR3220 / MR3420-ast és arra dugod az USB-s cuccokat
-
Peter789
senior tag
válasz
vargalex
#813
üzenetére
értem... akkor marad a flash, csak megy mellé az SD, és boot közben egyből mount-olódhat is mint rootfs. gondolom annak nincsen jelentősége, hogy melyik GPIO lábakhoz rendeli az ember a CS lábakat (az AR933X-on nem szívesen áldoznám fel az UART-ot), ellenben a legtöbb LED totál felesleges...
-
Peter789
senior tag
ígéretes írás látott napvilágot az orosz openwrt wikin: [link] - a google translate segít nagyjából megérteni...
pont ezt kérdeztem előbbre, hogy talált e már valaki olyan írást, ahol SD kártyát drótoztak a hardveres SPI buszra, nem soft-SPI GPIO-s meghajtással működik... bár engem akkor már leginkább a második fele fog érdekelni, amikor egy az egybe ki is váltják, akkor talán még gyorsabb lesz az elérése...
-
Peter789
senior tag
találtam az /etc/mpd.conf -ban egy ilyet:
#id3v1_encoding "ISO-8859-1"
default-ból ki van kommentelve, de beraktam egy ilyen sort és újraindítottam:
id3v1_encoding "CP852"
a kmod-nls-cp852_3.3.8-1_ar71xx.ipk fent van, de letojja, továbbra is csak fals karakterekkel ír ki minden magyar ékezetet - a 852-es kódlap kellene pedig, nem?
mondjuk egyelőre találtam más megoldást, ami hosszútávon lehet jobb is nekem: magát az mpc-t egy php program hívogatja meg, az vezérli egy webfelülettel. így a php kódba tettem egy konstans táblát, ami kicseréli a fals karakterpárokat a helyesre. mivel hosszútávon az lenne a cél, hogy multinacionális legyen a program és mindenféle rádiók infó sorait meg tudja jeleníteni, így nem is kellene az mpd-t egy adott karakter kódlaphoz kötni - jobb az ha on-the-fly javítom a hibákat, így minden nyelvhez tud igazodni... vagy esetleg valaki tud ennél jobb megoldást?
-
Peter789
senior tag
sziasztok ismét!
mit kell telepíteni ahhoz, hogy az ékezetes karakterekkel is elbánjon az openwrt? felraktam az összes kmod-nls-* csomagot, de az mpc továbbra is törötten jeleníti meg a magyar stream szövegeket:
root@OpenWrt:~# mpc status
RA!diA3 1: Kelly Clarkson:Stronger (What Doesn't Kill You)
[playing] #1/1 5:47/0:00 (0%)
volume:100% repeat: off random: off single: off consume: offvagy ez a program limitációja és nem is fog menni?
-
Peter789
senior tag
válasz
vargalex
#724
üzenetére
az olcsó modern USB-s tunereknél nem jellemző a hardveres tömörítés, plussz ha lenne, akkor ahhoz meg nem nagyon lesz openwrt-hez driver. viszont jobban belegondolva a webkamerák képét is simán lehet stream-elni - azok se tömörítik hardverből - akkor valószínűleg a TV adással se lenne gond...
-
Peter789
senior tag
válasz
vargalex
#717
üzenetére
de se kernel, se mtd partíció védelem nincsen még sehol ha uboot parancssor alól végzed a másolást. akkor csak nyers flash terület van sok sok byte-al amit átmásolsz
céleszközöm nekem sincsen, mezei 4e forintos hobby hőléggel szedtem le a csippet a fél gigás DDR1 noti modulról és a router alaplapjáról is, majd némi tisztítás után a weller pákával forrasztottam a helyére. az első leműtésnél még segítségül hívtam egy hőkamerát, azzal néztem ahogy melegszik a nyák, és bő 200 foknál egyszerűen levált a csipp. utána már nem is használtam, elég csak határozott gyors körbejárós mozdulatokkal melegíteni, közben pedig egy lapos pengével finoman emelni a csipp szélét és egyszercsak leugrik a helyéről... körültekintően, óvatosan, mert más alkatrészek is kilágyulhatnak körülötte és nehogy sikerüljön lesodorni
-
Peter789
senior tag
válasz
vargalex
#715
üzenetére
igen, emlékezetből írtam és tényleg kellenek a CS felhúzók...
viszont miért kellene a kernel mod a szimpla másoláshoz? uboot parancssorból is el lehet intézni a teljes másolást a forrás memóriába feltöltésével majd flash-be visszaírásával, nem? ha nagyobbra cseréled a flash-t az már persze más kérdés...
sajnos a flashcsipp levételének azért megvannak a veszélyei, nem egy olyan panaszt olvastam hogy sikerült feltépni rézfóliát a nyákról. mondjuk amikor hőléggel cseréltem a RAM csippet, akkor szerencsére nem volt semmi gondom, de azért óvatos is voltam amikor a padokat tisztítottam a 60W-os wellerrel
az SPI-SD modra nem találkoztál valahol leírással? sajnos nem tartok még ott hogy magamtól megcsináljam, de ha lenne valami kiinduló alap, akkor talán sikerülne... rákeresve a témára csak a soft SPI-s megoldásokra találok példákat...
-
Peter789
senior tag
válasz
vargalex
#710
üzenetére
olvastam egy hardveres oldalról hasonló, szoftveres oldalról jóval egyszerűbb megoldást nemrég valamilyen MR3220/3420-as topikban: egyrészt párhuzamosan beforrasztott a CS kivételével minden lábat, másrészt a CS-t megszakítva egy ponton (talán valami soros ellenállásnál, vagy átvágva a nyákon, ezt nem tudom) úgy hogy könnyen át lehessen kötni a 2 chip között menet közben. vasat indítja a belső flash-ről uboot-ig, komplett flash image RAM-ba fel > CS átköt > komplett image flash-be kiírása... így nem kell egyedi kernellel bűvészkedni hozzá...
viszont ezzel párhuzamosan lenne nekem is egy kérdésem. ezekszerint a plussz MTD flash "viszonylag egyszerűen" megoldható... és mi a helyzet mondjuk egy SPI-re kötött SD kártyával? a soft-SPI elég lassú és erőforrászabáló (plussz a megbízhatósága sem tudom milyen). ehhez mire lenne szükség - gondolom szintén egyedi kernel? láttatok már valahol ilyen projektet?
-
Peter789
senior tag
-
Peter789
senior tag
válasz
Peter789
#641
üzenetére
ugyanaddig jutok vele akkor is, ha manuálisan definiálom, nem luci-val... egyértelműen él, belép, de eldobja magát az usb eszköz rögtön a csatlakozás után... valakinek van rá ötlete, hogy hogyan lehetne tovább vadászni a hiba okát?
...
Dec 9 13:49:25 OpenWrt user.notice usb-modeswitch: 1-1.1:1.9: Manufacturer=ZTE Product=MF195 Serial=4E6BB99B6ED65D20664F6E0A5C41F9C405C62793
Dec 9 13:49:26 OpenWrt daemon.notice pppd[1914]: pppd 2.4.5 started by root, uid 0
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: abort on (BUSY)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: abort on (NO CARRIER)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: abort on (ERROR)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: report (CONNECT)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: timeout set to 10 seconds
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: send (AT&F^M)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: expect (OK)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: AT&F^M^M
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: OK
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: -- got it
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: send (ATE1^M)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: expect (OK)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: ^M
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: ATE1^M^M
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: OK
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: -- got it
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: send (AT+CGDCONT=1,"IP","internet"^M)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: timeout set to 30 seconds
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: expect (OK)
Dec 9 13:49:27 OpenWrt local2.info chat[1918]: ^M
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: AT+CGDCONT=1,"IP","internet"^M^M
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: OK
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: -- got it
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: send (ATD*99***1#^M)
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: expect (CONNECT)
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: ^M
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: ATD*99***1#^M^M
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: CONNECT
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: -- got it
Dec 9 13:49:28 OpenWrt local2.info chat[1918]: send ( ^M)
Dec 9 13:49:28 OpenWrt daemon.info pppd[1914]: Serial connection established.
Dec 9 13:49:28 OpenWrt daemon.info pppd[1914]: Using interface 3g-wan
Dec 9 13:49:28 OpenWrt daemon.notice pppd[1914]: Connect: 3g-wan <--> /dev/ttyACM0
Dec 9 13:49:35 OpenWrt daemon.notice pppd[1914]: local IP address 188.156.147.65
Dec 9 13:49:35 OpenWrt daemon.notice pppd[1914]: remote IP address 10.0.0.1
Dec 9 13:49:35 OpenWrt daemon.notice pppd[1914]: primary DNS address 84.2.44.1
Dec 9 13:49:35 OpenWrt daemon.notice pppd[1914]: secondary DNS address 84.2.46.1
Dec 9 13:49:35 OpenWrt daemon.notice netifd: Interface 'wan' is now up
Dec 9 13:49:35 OpenWrt user.notice ifup: Enabling Router Solicitations on wan (3g-wan)
Dec 9 13:49:36 OpenWrt user.info firewall: adding wan (3g-wan) to zone wan
Dec 9 13:49:39 OpenWrt daemon.info dnsmasq[1528]: reading /tmp/resolv.conf.auto
Dec 9 13:49:39 OpenWrt daemon.info dnsmasq[1528]: using nameserver 84.2.44.1#53
Dec 9 13:49:39 OpenWrt daemon.info dnsmasq[1528]: using nameserver 84.2.46.1#53
Dec 9 13:49:39 OpenWrt daemon.info dnsmasq[1528]: using local addresses only for domain lan
Dec 9 13:49:41 OpenWrt kern.info kernel: [ 76.730000] usb 1-1.1: USB disconnect, device number 5
Dec 9 13:49:41 OpenWrt daemon.notice pppd[1914]: Modem hangup
Dec 9 13:49:41 OpenWrt kern.info kernel: [ 76.740000] cdc_ether 1-1.1:1.5: usb0: unregister 'cdc_ether' usb-ehci-platform-1.1, CDC Ethernet Device
.../etc/config/network :
config interface 'wan'
option ifname ppp0
option proto 3g
option device /dev/ttyACM0
option apn internet -
Peter789
senior tag
ismét visszatérek egy 3g modemes problémával
szereztem egy trémobil MF195-ös modemet. windows alatt 19d2:1210-nek látszik, majd telepítés után átvált 19d2:1211-re és felrak 3 sorosportot. utána működik stabilan
ubuntun ott kezdődött a szívás, hogy a modeswitch profilok között ilyen nincsen. gugliztam az MF195-re, és a hup-on találtam egy szintén MF195-nek eladott, de teljesen más PID-el rendelkezőre leírást. végigpróbáltam egy csomó hasonló, apróságokban eltérő usb_modeswitch MessageContent-et, és 1-2 sikertelen kísérletet leszámítva minddel ugyanarra jutottam: a 1211 helyett 1212 lesz a PID és nem 3 sorosport, hanem 2 soros (ttyACM0/1) + egy cdc-ether (usb0) eszközként jelenik meg. az ubi grafikus felületén utána egyből lehet csatlakozni és stabil a net
utána jött az openwrt: felraktam a kmod-usb-net-cdc-ether modult, a modeswitch-et bekonfigoltam ugyanúgy ahogy az ubuntun, át is váltja ugyanúgy 2 soros + cdc-ether -re. utána a luci-n (3g plugin telepítve) próbáltam hozzáadni mint új modem: umts/gprs/evdo proto, umts/gprs service, internet apn, pin/user/pass üres, portnak próbáltam a ttyACM0 és 1-et is, ugyanúgy viselkedett mindkettőnél: csatlakozik, az ifconfig-ban pillanatra meg is jelenik az interfész, de azzal le is szakad az usb eszköz és újracsatlakozik 1210 telepítő módban, majd jön az usb_modeswitch... végtelen körforgás, ha a modeswitch-et automatán hagyom... egy pillanatra még az értelmes megkapott IP cím is látszik az ifconfig-ban! nem hiszem hogy az áram lenne kevés a porton, mert tettem egy izmos elkót a HUB-ba - előtte volt hogy a pendrive-ot is elvesztette ha mást mellé dugtam, most minden stabilan viselkedik - kivéve ezt a modemet. persze ha nincsen jobb ötlet, akkor próbálok külső tápot adni majd neki... de eddig már több különböző modem, hangkártya, egyéb HID eszköz volt rajta akár egyszerre is és tápproblémát még a 21 mbit-essel sem tapasztaltam, ez meg csak egy 7-es...
valamit félrekonfigolok talán? a cdc-ether eszközökre nem igazán találtam semmi értelmes leírást - inkább androidos telefonoknál emlegetik, de ott nem "tárcsáz" senki sehová, a telefon készen adja a netet a cdc-ether hálón keresztül, csak dhcp-vel rá kell csatlakozni - ha jól értem...
-
Peter789
senior tag
válasz
m_kovacs
#633
üzenetére
ha nincsen semmi olyan a rendszeren amit ne tudnál reprodukálni és úgyis csak kísérletezgetsz még a rendszerrel, akkor szerintem a legegyszerűbb teljesen tiszta lappal kezdeni: [link]
mtd -r erase rootfs_data
a squashfs-t kiegészítő jffs2 partíciót teljesen nullázza, ezáltal olyan állapotot kapsz mintha most húztad volna rá frissen a firmware-t
-
-
Peter789
senior tag
válasz
vargalex
#620
üzenetére
igaz, mivel nem vagyok nagy guruja a témának csak ismerkedek vele és már sokmindent összekukáztam lírások alapján, így pongyolán fogalmazok még és keverhetem a fogalmakat is...
m_kovacs: nincs mit, legrosszabb esetben egy újrahúzás is ismét lehet nekifutni, nagyobb kárt nem lehet okozni vele
-
Peter789
senior tag
válasz
m_kovacs
#611
üzenetére
egyáltalán nem olyan vészes mutatvány, percek alatt össze lehet rakni!
a következő csomagok kellenek (az alap usb támogatás általában már fent van, csak a storage és fs hiányzik - ha a dmesg-ben megjelenik a csatlakoztatott eszköz sora, épp csak a partíciókat nem látja rajta, akkor már csak a 2 utolsó hiányzik):
kmod-usb-core Kernel support for USB
kmod-usb2 Kernel support for USB2 (EHCI) controllers
vagy (1043-hoz gondolom az usb2 kell)
kmod-usb-ohci Kernel support for USB OHCI controllers
kmod-usb-storage Kernel support for USB Mass Storage devices
kmod-fs-ext4utána a csatlakoztatott eszköz megjelenik, mint sda1-2-3, sdb1-2-3 stb eszköz a dmesg-ben
a manuális mount:
mount -t ext4 /dev/sda1 /mnt/sda1 -o rw,sync
(előtte mkdir-el létre kell hozni a mount point-ot)majd a pendrive-ra másolt fájlra rámutatsz egy softlink-el onnan ahol lennie kellene a fájlodnak:
ln -s /fájl_valódi_helye /ahol_nem_fér_elde akkor már érdemes továbbmenni az extroot-al, amihez még ez a csomag kell: block-mount
majd átmásolni a mount-ra a rootfs tartalmát:
tar -C /overlay -cvf - . | tar -C /mnt/sda1 -xfmajd a /etc/config/fstab-ban hozzáadni (vagy szerkeszteni ha van is_rootfs-es rész) :
config mount
option device /dev/sda1
option fstype ext4
option options rw,sync
option enabled 1
option enabled_fsck 0
option is_rootfs 1ennyi... elvileg a következő bútolás után már ha nyomsz egy df -m / -t akkor azt látod van sok sok helyed, mivel a pendrive-on dolgozol...
ha a pendrive ext4-re formázásához nincsen linuxod, akkor vmware-be rakj egy ubuntu-t, abba telepíts egy gparted-et és abból intézheted
-
Peter789
senior tag
válasz
m_kovacs
#609
üzenetére
nem vagyok guru, de ajánlom az extroot-ot egy pendrive-al és többé nem lesz helyhiányod. a lényege hogy elég csak annyi modul a belső flash területre amivel már képes mount-olni a külső meghajtót, átmásolod az egész / tartalmát oda majd beállítod hogy induláskor ennek a helyére húzza be ezt a külső területet. ajánlom az ext4 fájlrendszert, mostanában elég sokat kínoztam hirtelen újraindításokkal és eddig semmi hibáját nem tapasztaltam - minden induláskor mount-olásnál csinál egy logikai helyreállítást
-
Peter789
senior tag
sajnos ez már olyan ingoványos rész amihez egyáltalán nem értek, de kitartással előbb utóbb mindent meg lehet oldani
mondjuk tény hogy egyszerűbb lenne az élet, ha valami mezei HID vagy soros eszköz lenne. ha a forráskódja publikus, akkor valahogyan azt a perl modult is biztosan le lehet forgatni a céleszközre... -
-
Peter789
senior tag
én az ismeretlen drivereket / kernel modulokat használó eszközöket úgy szoktam éleszteni, hogy vmware-be húzott ubuntun először lekérek egy lsmod-ot, majd csatlakoztatom az eszközt és utána ismét (feltéve persze hogy az ubuntu felismeri) - így látszik hogy milyen modulokat csatol alá az ubi, van miből kiindulni hogy milyen nevű package-eket kell összevadászni
feltehetően vagy valamilyen USB>soros chip van benne (FTDI, Silabs, Prolific, WCH, stb), vagy USB HID vagy HIDRAW eszközként jelenik meg - ha utóbbi akkor jöhet ugyanaz a szívás amit nekem kellett végigjátszani - újra kell fordítani a HID kernel modult, mert alapból nincsen benne a támogatása
-
Peter789
senior tag
válasz
vargalex
#596
üzenetére
köszi, sikerült is...
viszont lenne egy újabb problémám: sehol sem találok perl device::serialport csomagot az MR3220-ra... próbáltam ar71xx, mips, mips32-vel keresni, de semmi. egyéb architektúrákra találtam sokat, de erre semmit. egy mipsel volt eddig a legközelebbi, de azt persze nem eszi meg. pedig régebben tudom hogy már használtam ilyet, csak azóta már nem egyszer letakarítottam a vasat és most nem találom a forrást - egy döglött dropbox megosztás mappát találtam csak, lehet annó onnan szedtem le, de már nem él a link. csak rosszul keresem, vagy tényleg nincsen sehol?
-
Peter789
senior tag
-
Peter789
senior tag
nem a lovon múlik... a fellelhető "irodalom" és gyakorlati tesztjeim alapján is 57600-on már sűrűn bakiztak az ilyen kapcsolások, 115200-on pedig abszolút törött karakter tenger volt az egész. 4800-9600-as baudrate-et használó kapcsolásaimban én is használok több helyen ilyeneket, de magasabb sebességet inkább nem is kockáztatok - oda MAX232 megy ha 5V és MAX3232 ha 3.3V-os a környezet... csak itthon drágák a MAX3232-k (250-700Ft/db), kínából házhoz hoz a postás 500Ft-ért 10 darabot
-
Peter789
senior tag
a tranyós megoldást azért nem is ajánlgattam, mert az ide szerintem nem lesz elég... ahogy látom 9600-as baudrate kell a lafonera-nak - mikrokontrollerek mellett én is használtam ilyen tranyós kapcsolásokat, de max 38400-ig volt stabil - ezeknek az újabb atheros-os platformoknak viszont már 115K2 baud kell, amihez a mezei 2N2222, 2N és MMBT/3904, BC54x és 84x tranyók nem elég gyorsak. biztos létezik olyan amivel megoldható, de akkor már valszeg olcsóbb, beszerezhetőbb a MAX3232 vagy az USB > TTL soros adapter
-
Peter789
senior tag
többféle módon is megoldható...
ha van hagyományos sorosportod, akkor egy MAX 3232 illesztő IC-s kapcsolás kell:
össze lehet rakni házilag is, de készen is meg lehet őket kapni: [link], [link]
vagy USB > TTL soros adapterrel: [link] - olcsó hazai ha tudsz ilyen kis pontokra forrasztani, [link]
a vaterás az valszeg valami régi mobil adatkábel lehet... ha van ilyened vagy tudsz szerezni, akkor az lehet még jó...
-
Peter789
senior tag
-
Peter789
senior tag
sziasztok ismét!
újra kellene fordítanom a hid kernel modult, mert ha minden igaz, akkor gyárilag valamiért kihagyták a hidraw opciót és nekem most erre lenne szükségem...
leszedtem az openwrt oldaláról a teljes csomagot ami az MR3220-hoz kell:
svn checkout svn://svn.openwrt.org/openwrt/branches/attitude_adjustmenta make menuconfig-ban csak nagyvonalakban tudom kiválasztani, hogy legyen hid támogatása is, de a lényegi alopciókat nem érem úgy el, mint a kernel menuconfig-ban. próbáltam a kernel alkönyvtár .config fájljában átírni a n-t y-re, de amikor futtattam a make-et, egyből visszaugrott n-re és természetesen nem is került bele a kész modulba az opció. gondolom valami máshol található default config-al írja felül - ott kéne módosítanom - de ezt hogyan tudom kideríteni, hogy hol is kellene átírnom?
-
Peter789
senior tag
milyen fájlrendszert célszerű használni pendrive-hoz olyan környezetben, ahol bármikor elszállhat a táp? a FAT/32 úgy tudom nagyon sérülékeny... az ext2/3/4 tűri, ha írás közben kiszalad a vas alól a táp? magától rollback-elődik következő bútolásnál? vagy mi a legjobb választás?
-
Peter789
senior tag
véletlenül pont a testvértípusra találtam egy rövid leírást: [link]
ezzel simán lehet írni a flash-t ha van LPT portod - kérdés hogy a uboot / redboot rész honnan lesz meg... vagy még él a mostani flash tartalma valamennyire, a boot rész esetleg menthető belőle? az általad is linkelt openwrt wikin ott van hogy melyik partíció mettől meddig tart...
flash csippet vagy íbéjről szereznék, vagy esetleg a chipcad-nél is akad [link], csak kérdés hogy a bootmanager van e annyira intelligens hogy pl az azonos tokozású 128mbit-est is le tudja e kezelni
-
Peter789
senior tag
eljutottam odáig, hogy már sikerült felélesztenem egy mini PCIe-s GTM380-as modemet egy "homemade" PCIe - USB adapterben - tárcsáz, netre lép, IP címet kap - a rúterről lehet is kifelé pingelni, letölteni, viszont a rácsatlakozó gépnek nem adja át a netet... gondolom valami tűzfalas probléma lehet. a probléma ott kezdődik, hogy ez a modem már nem 3G, hanem HSO proto-t használ, amit a Luci nem ismer. próbáltam úgy csalni, hogy először létrehoztam egy alap 3G modemes WWAN profilt, ugyanolyanra állítottam mindent mint egy már működő másik modemmel - hagytam hogy lementsen minden tűzfal beállítást a Luci - majd átírtam fájlrendszer szinten a network configban amit kellett, és tárcsáztam. a rácsatlakozó eszköz továbbra se kap netet. azzal is próbálkoztam már, hogy a WAN eth1-et #-oltam a konfigból és a HSO-t neveztem el WAN-nak, reboot, de a külső eszköz továbbra se megy. hol lehet a probléma ? valaki aki jártasabb a témában segítene átgondolni, hogy hogyan is kell felépíteni fs szinten egy ilyen eszköz hozzáadását ? tűzfal, route-ok, stb stb...
-
Peter789
senior tag
válasz
vargalex
#482
üzenetére
igazából nem is tudom miért... régebben olvastam valami nyúlfaroknyi összefoglalót és abból azt szűrtem le hogy az jobb nekem, de most átfutottam még pár oldalt és tényleg szimpatikusabb a squashfs-es megoldás...
a soros kábelt azért használom, mert egyrészt rá van kötve hogy kényelmesen, külön lekérdezgetés nélkül lássam a kernel üzeneteket, másrészt már többször is sikerült úgy összebarmolnom a rendszert hogy volt hogy be se bútolt, volt hogy elindult de mindenre hibaüzeneteket dobált, stb... megszoktam, egyszerű a pár megás image-el
amikor egy samsung procis alaplappal játszom, akkor marad a uboot és tftp > az 50 megás jffs2 image áttöltését már nincsen kedvem kivárni 115K2 baudon ráraktam a squash-t és most teljesen jól viselkedik... lehet eddig is ezt használtam és csak trunk-ból a jffs2-t?
-
Peter789
senior tag
sziasztok ismét!
érdekes proglémába futottam, hátha valaki fogja rá tudni a választ...
a TL-MR3220 v1.2-es rúteremen előbbre a trunk 3.3.8-as kernel verziós jffs2 openwrt-t futtattam, majd szeptember elején kijött egy szintén 3.3.8-as, de már attitude_adjustment, Luci-val, ezért ráhúztam ebből is a jffs2-est. működött is tökéletesen, csak hát sokat gyilkoltam és most jutottam el oda, hogy újra kellene darálni. a szeptemberben leszedett verziót nem találtam a gépemen, ezért újra leszedtem (a dátum nem változott: 04-Sep-2012 19:11) - viszont most ráhúzva valamiért nem bútol be rendesen... eljut a failsafe sorig - ha nyomom az F+ENTER-t akkor be is lép. viszont ha hagyom továbbmenni, akkor az ohci_hcd: USB 1.1 OHCI driver sornál elakad és többé nem lép tovább... hiába nyomom az ENTER-t, nem ad soros konzolt csak léptet 1-1 sort (talán nem lefagyott), nem látszik az OpenWrt default SSID és nem ad IP-t a kábellel rádugott gépnek... ha a squashfs-est húzom rá azzal rendesen elindul és működik is - de én inkább a jffs2-t preferálnám...
előfordulhat, hogy annak ellenére hogy nem változott a dátum az openwrt letöltés listájában [link], mégis feltöltöttek valami új verziót ami bugos és azért nem indul el most? vagy nem látom a fától az erdőt és valamit elfelejtek?
USB soros kábellel csatlakozok rá amikor frissítem, úgy lépek be a uboot-ba, majd (az openwrt 3420/3220-as leírására alapozva) :
erase 0x9f020000 +0x3c0000
loady (itt megkapja az image-et)
cp.b 0x81000000 0x9f020000 0x3c0000 -
Peter789
senior tag
sziasztok! próbáltam guglizni, de eddig nem találtam az elképzelésemre semmi megvalósítást, gondoltam hátha valaki már futott efféle cikkbe: a router alaplapján lévő SPI-s flashchip mérete kicsi, macerás a cseréje és az se lesz sokkal nagyobb. viszont az SPI-re rá lehetne kötni egy SD/MMC kártyát is, és az eredeti flash csippet kidobva ezt használni mint búteszköz. futott már valaki ilyen témába?
Új hozzászólás Aktív témák
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem.
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- GYÖNYÖRŰ iPhone 14 Pro 128GB Deep Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS4677
- Beszámítás! Apple MacBook Air 13 2020 M1 8GB RAM 256GB SSD notebook garanciával hibátlan működéssel
- Bomba áron dobozos Hp Laptop! /AMD Ryzen 5-7520U/8 GB/256 SSD/FHD/Garancia
- BESZÁMÍTÁS! Asus ROG Z790 i9 13900K 32GB DDR5 1TB SSD RX 7900 XTX 24GB Lian LI LANCOOL 207 ROG 750W
- iKing.hu Apple iPhone 12 Pro Max 128GB Gold használt, megkímélt 100% akku 6 hónap garancia
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest