V lete som tu mal dve telky a mal som moznost vyskusat tie dosky.
Vymena NAND tu prehriatu dosku neozivila. Processor sa vyrazne prehrieva. Viac ako ostatne. Ale to je mimo temy.
Porovnal som blok 2045 zo suboru co mam s druhym kde su tri vadne bloky.
Udaje v tomoto bloku su skoro identicke.
Okrem toho miesta kde su cisla blokov su len 3 miesta kde su rozne udaje.
Zistil si ze kde tam maju nejaky kontrolny kod CRC?
tu su tie 3 miesta kde to je ine. Je este jedno miest kde su 2 byty rozne. Neviem ci to je dolezite.
Bloky 2045 som vybral z oboch suborov a som urobil 2 ine mensie subory. Preto sa to zacina od nuly.
CRC BBT je na prvom obrázku, ale neviem prečo mám vzdialenosť od začiatku BBT do začiatku CRC o 8 bajtov ďalej ako ty, viď obrázky.
Môže íst o chybu zobrazovania jednho z editorov alebo rozdiel platforiem D55/57 vs tvoja.
Keď tak pošli odkaz na stiahnutie jedného s výsekov aby som to porovnal.
Vysek som bral od zaciatku bloku 2045 co je 2258465280dec (lepsie sa mi naraba s dec ako hex)
Inac sa mi zda ze BBT zacina o 8 bytov skorej.
Myslim ze to 00 00 ff ff je cast tabulky. Aky vyznam to ma neviem, ale je to potom zaciatok druhej stranky vzdialenej 8628 bytov od zaciatku bloku.
Nasiel som dalsi subor kde som nemal ziadne zle bloky a tam druha stranka zacinala ff ff ff ff.
Teda ked sa napise BBT, tak sa zacne od zaciatku druhej stranky s 00 00 ff ff a az potom tie presuny blokov.
No, este tak vyriesit CRC .....
To všetko viem avšak ja som začiatok BBT počítal od prvého bajtu označenia vadného bloku po prvý bajt CRC a vyšlo mi, že u teba je to o 8bajtov neskôr ako u mňa, tak som to napísal...(vzdialenost medzi BBT a CRC BBT alebo ako to nazývaš je u teba o 8 bajtov kratšia ako u mňa).
A ty mi na to napíšeš, že "Myslim ze to 00 00 ff ff je cast tabulky. Aky vyznam to ma neviem, ale je to potom zaciatok druhej stranky vzdialenej 8628 bytov od zaciatku bloku. ".
To je teda odpoveď? Lebo je uplne jedno kde je začiatok a koniec súboru ak tento obe veci aj všetko medzi nimi zahrnuje a či ide o celý dump alebo len jeho výsek, takže to vobec ten posun (rozdiel) 8 bajtov nevysvetluje a ani to, že či je adresácia v desiatkovej sústave alebo šestnástkovej.
A nebolo by ti lepšie ak by si aj všetky dáta mal v desiatkouve sústave? Aby tomu už vúbec nikto nerozumel?
No takže mne sa lepšie rozlišuje v hexa a neoznačujem v texte bajty ako byty, lebo byt a bit môže pre niekoho znamenať to isté.
A odkial vieš, že jedna stránka tejto nand je 8628 bajtov teda niečo cez 8kiloBajtov (kB)?
Stále píšeš nezrozumiteľne a opakuješ to čo už som písal predtým avšak bez otázky, či si to tak správne pochopil alebo nepochopil, ale ako fakt na ktorý si niekedy prišiel avšak ludí to potom mýli a aj mňa, čo vlastne tým chceš povedať.
Takže posledný krát Ta upozorňujem, že ak týmto spôsobom budeš ďalej komunikovať, tak ja už odpovedať nebudem.
A teraz budem citovať to čo si napísal jedno za druhým a rozvádzať to čo si napísal aby to bolo jasné nie len teraz mne ale aj zajtra niekomu druhému:
"Vysek som bral od zaciatku bloku 2045 co je 2258465280dec"
A čo keď si to bral odtial, má to nejaký vplyv na niečo ohladne posunu (rozdielu vzdialenosti BBT a CRC) o 8 bajtov alebo na čokoľvek iné?
"(lepsie sa mi naraba s dec ako hex)" Ale bežne zaužívané to tak nikde nie je.
"Inac sa mi zda ze BBT zacina o 8 bytov skorej."
Tebe sa teda zdá, čo som už prepočítaval v predošlej správe alebo teda ako tomu mám rozumieť? A ak áno, ako potom vysvetlíš ten posun aj keď ja asi tuším ako vznikol, ale vysvetli to ty, lebo si ho urobil ty. Do tejto správy mi to nebolo jasné, ale teraz už mi to jasné začína byť.
"Myslim ze to 00 00 ff ff je cast tabulky. Aky vyznam to ma neviem, ale je to potom zaciatok druhej stranky vzdialenej 8628 bytov od zaciatku bloku. "
Na základe čoho si to myslíš? A odkial si došiel na to, že 8628 bajtov alebo 8627 bajtov je veľkosť jednej stránky tejto pamäte?
To všetko vysvetli, lebo tu žiadne myslím nemá žiadny zmysel, ked nevysvetlíš na základe čoho.
Kde si našiel ďaľší súbor, keď máš len 2 dosky? A tento súbor nemá zápis v BBT, čo neznamená, že pamäť z ktorej je stiahnutý nutne nemá zlé bloky.
Takže by som to na tvojom mieste pomenoval tak, že BBT je bez zápisu vadných blokov
Ahá to je vysvetlenie na základe čoho si myslíš, že 0000FFFF pred označením prvého chybného bloku je súčasť BBT v dunpe od pamäte kde BBT má zápis vadného bloku vs BBT, ktorá nemá zápis vadného bloku.
Myslím si, že s američanom čo by písal cez translátor po slovensky by som si lepšie porozumel ako s tebou.
Nebudem sa k tvojmu spôsobu písania dalej vracat, proste už neodpoviem ak budem muset nad tým, čo píšeš premýšlať desiatky minút.
Súbor si neposlal, takže viacej sa vyjadriť k tvojej záhadnej reči už neviem.
Naposledy upravil Heno dne pá listopad 16 2018, 12:09, celkově upraveno 2 krát.
Ako vieš, že je to CRC a nie kontrolná suma a či je to len jedna alebo je ich viac, to tiež myslím nikto z nás nevie a poprosím rnbw ak toto číta a už rozumie o čo približne ide, nech sa skúsi vyjadriť.
"
Myslím si, že s američanom čo by písal cez translátor po slovensky by som si lepšie porozumel ako s tebou.
Nebudem sa k tvojmu spôsobu písania dalej vracat, proste už neodpoviem ak budem muset nad tým, čo píšeš premýšlať desiatky minút. "
Prepac technicku slovencinu nepouzivam uz viac ako 20 rokov, ale keby si chcel mozem kludne po anglicky.
"Na základe čoho si to myslíš? A odkial si došiel na to, že 8628 bajtov alebo 8627 bajtov je veľkosť jednej stránky tejto pamäte?
To všetko vysvetli, lebo tu žiadne myslím nemá žiadny zmysel, ked nevysvetlíš na základe čoho. "
Neverim, ze si nestudoval datasheet na K9GAG08U0E, tak ti to potom asi uslo. Pozri si obrazok, tam je vysvetlene odkial mam tie cisla.
Dalej neverim, ze nieco tak dolezite ako BBT by programator len hodil niekde do pamete na hocijake miesto. To 00 00 ff ff je zaciatok druhej stranky v bloku 2045. To moze byt dolezite pri ratani CRC alebo co ja viem co sa tu rata.
"Kde si našiel ďaľší súbor, keď máš len 2 dosky? A tento súbor nemá zápis v BBT, čo neznamená, že pamäť z ktorej je stiahnutý nutne nemá zlé bloky. "
Prvy televizor s tym problemom som opravil v 2014 a od vtedy som ich urobil uz niekolko. Roznych suborov mam stovky ked nie tisice ked beriem do uvahy aj tie co si poskytujeme medzi kolegami. Takze, ano nasiel som. A mozno mam aj viac, len treba hladat.
"Ako vieš, že je to CRC a nie kontrolná suma a či je to len jedna alebo je ich viac, to tiež myslím nikto z nás nevie a poprosím rnbw ak toto číta a už rozumie o čo približne ide, nech sa skúsi vyjadriť."
Neviem.
Myslel som, ze ty vies. To som sa presne pytal ci vies co to je a kde to je.
Pisal si nieco o tom v prvom prispevku a neviem ako by som to mal nazvat.
"Navyše BBT je chránená kontrolnou sumou, tak na dodatočné ručné vytvorenie platnej a fungujúcej BBT je potrebné vedieť algoritmus výpočtu kontrolnej sumy a adresu v pamäti, kde je suma uložená aby ju sw TV akceptoval a aj sa podľa nej riadil. "
"Prepac technicku slovencinu nepouzivam uz viac ako 20 rokov, ale keby si chcel mozem kludne po anglicky. "
Nejde len o technickú slovenčinu, ale aj o spôsob vyjadrovanie, kd enebolo zjavné či sa pýtaš alebo odpovedáš...Naštastie teraz už je to zrozumiteľné.
"Neverim, ze si nestudoval datasheet na K9GAG08U0E, tak ti to potom asi uslo. Pozri si obrazok, tam je vysvetlene odkial mam tie cisla.
Dalej neverim, ze nieco tak dolezite ako BBT by programator len hodil niekde do pamete na hocijake miesto. To 00 00 ff ff je zaciatok druhej stranky v bloku 2045. To moze byt dolezite pri ratani CRC alebo co ja viem co sa tu rata. "
Už dávno som to prezeral inak by som nevedel o ECC 24/1kB, len som donedávna ignoroval fakt, že by pre mňa z hladiska riešenia toho čo ešte neviem bolo potrebné sa orientovať v tom, že treba deliť jeden blok ešte na počet 8kB stránok, takže názov "stránka", ktorý som použil pri založení tohoto vlákna bol myslený len obrazne ok 1kB časť pamäte a teraz názov stránka (page) už znamená 8kB. Takže doplním aj pojmy na začiatku vlákna. Jednoducho zpočiatku som pochopil, čo treba preniesť do druhého dumpu aby to fungovalo a nezamýšlal som sa nad tým prečo. To až neskôr keď človeku začínajú dávať zmysel ďaľšie súvislosti a na to som to sem aj písal aby som ešte viac pochopil a somnou aj iní pochopili čo viem ja, ale oni ešte nie a naopak.
"Prvy televizor s tym problemom som opravil v 2014 a od vtedy som ich urobil uz niekolko. Roznych suborov mam stovky ked nie tisice ked beriem do uvahy aj tie co si poskytujeme medzi kolegami. Takze, ano nasiel som. A mozno mam aj viac, len treba hladat."
O tom si predtým nepísal, takže som sa preto pýtal odkial to máš.
Predpokladám, že si ich opravil len kopírovaním funkčného dumpu do inej pamäte, kde nefunkčný dump predtým spôsoboval závadu reštartov TV.
"Neviem.
Myslel som, ze ty vies. To som sa presne pytal ci vies co to je a kde to je.
Pisal si nieco o tom v prvom prispevku a neviem ako by som to mal nazvat."
Ani ja som nevedel, preto som sa pýtal, že ako vieš, že ide o CRC.
Doteraz som si nebol istý avšak ty si už tretí, čo mi nezávisle na sebe potvrdil analýzou vzoriek, že ide o ECC, takže sa na tom dá ďalej stavať.
Takže to presne popíšem ako si myslím, že to funguje:
Jedna stránka page (8628 bajtov) je v rozsahu od 0-21B3 hexa (0-8627) cellkovo.
Z toho základná časť page je 8kB (8192 bajtov) v rozsahu 0-1FFF (0-8191) a tzv. spare čast je 436 bajtov od 2000-21B3 (8192-8627).
1 blok pozostáva z 128 stránok page 8628 bajtov a z 1024 stránok (1024 bajtov + 54,5 bajtu), takže velkost jedného bloku je v hexa 100000 + spare 00DA00 hexa.
Na začiatku každej page stránky (a aj bloku) použitej v systéme je prvých 4 bajtov hlavička, ktorá označuje druh dát, ktoré sa v hlavnej časti page stránky budú nachádzať. (hlavná časť od 0 do 1FFF, hlavička od 0 do 03).
Adresou 2000 začína spare časť page stránky (2000-21B3 - 436 bajtov).
Na začiatku od 2000-2003 tiež nájdeme hlavičku veľkosti 4 bajtov, ktorá zrejme určuje spôsob výpočtu ECC.
V spare oblasti jednej stránky page je vidno 8 súm ECC, čo teda naozaj sedí s predpokladom, že každá 1kB stránka má svoju ECC.
Ale to je tak asi všetko, čo ma napadlo. Ako sa ECC počíta je záhadou.
Jelikož už jsem podobnou věc řešil s kolegou Heněm emailem, ale přes mou nevědomost jsem si smazal původní obsahy NAND, nemohl jsem pokračovat v laborování. Teď mi přišla pod ruku jiná deska s boot-loopem. Udělal jsem pro jistotu 5x dump tzn. mám teoreticky původní BBT. Problém u mě vyvstává z toho, že jsem bohužel koupil ne zcela dobrý programátor a to "TL86-Plus PROMAN". Sice se tváří, že umí zmiňované K9GAG08U0E, ale jistotu nemám. No a co je tedy problém, v bloku BBT je méně zápisů vadných bloků než bych očekával ve srovnání s informacemi, které vypisuje sw pro programátor. Jak tedy postupovat dále. Jo a ještě prosba, neměl by někdo z vás 100% funkční dump. Mám sice postahované z elektroda.pl a remontaud.ru, ale nerad bych laboroval a zbytečně ztrácel čas pokud by tyto dumpy nebyly funkční.
Přikládám log výpisu sw pro programátor a screenshot z HEX editoru.
Začnem od konca.
Ak už máš nabastenú objímku TSOP48 na MB BN41-01660 a si si istý, že nand so zaručene funkčným obsahom osadená v objímke tejto dosky funguje ako má, to znamená, že TV s touto doskou normálne funguje, potom zas tolko času nestráviš nad zisťovaním funkčnosti konkrétneho dumpu.
Podmienky počiatočného testu dumpu sú - týka sa novej nand pamäte:
NAND pamäť do ktorej nahraješ dump v ideálnom stave nemá mať žiadne vadné bloky podľa ZVB okrem 2073 (ten má každá).
Neviem presne čo sa momentálne chystáš skúšať.
Či sa snažíš opraviť obsah starej originál NAND s BBT, ktorú si dal do obrázku alebo či skúšaš samotnú funkčnosť objímky v doske za predpokladu, že doska je inak plne funkčná.
Nároky na funknosť dumpu vhodného na použitie na opravu starých pamätí resp. na nahratie nových:
- po maile sme sa bavili, že Proman na K9GAG08U0E spôsobuje prehadzovanie bajtov medzi sebou (prvý s druhým) takže neviem, či vôbec má zmysel to testovať s promanom, kým sa neodstráni táto závada promanu a ak, tak sa pokúsiť nájsť novšiu verziu obslužného softu pre proman, ktorá možno má túto chybu odstránenú a pred ďaľšími testami je nutné si overiť, či už nedochádza k prehadzovaniu bajtov
- Ak proman automaticky preskakuje pri nahrávaní dumpu do nand prázdne miesta t.j. miesta so samími FF, má zmysel pre rýchlejšie testy použiť neúplný dump, ktorý nemá nainštalované žiadne aplikácie smart, pretože tie sa automaticky updatujú po úspešnom spustení smart tv pripojeného na net.
Preskakovaním FF sa urýchli zápis do nand... Elnec a iné programátory túto funkciu majú, čo môže aj 2-3 násobne urýchliť zapis do pamäte.
- Teda okrem základného testu funkčnosti dumpu ako je kontrola smart, kontrola e-manuálu je treba otestovať schopnosť úspešného sw updatu TV cez USB ak má doska pamäať s testovacím dumpom, ktorý sa inak tvári v poriadku.
Niektoré dumpy sa totiž tvária ako funkčné avšak majú poškodenie, ktoré spôsobí počas sw update pád systému a dôjde k havárii dosky - poškodenie obsahu IC1301 OneNand.
Teraz napíšem čo hovorí BBT, ktorú si sem hodil:
- dáta čo by mali padnúť na blok číslo 1D5 (469) sú presmerované do rezervného bloku 7FB (2043)
- dáta čo by mali padnúť na blok číslo 1D6 (470) sú presmerované do rezervného bloku 7FA (2042)
- dáta čo by mali padnúť na blok číslo 363 (867) sú presmerované do rezervného bloku 7F9 (2041)
- dáta čo by mali padnúť na blok číslo 5FD (1533) sú presmerované do rezervného bloku 7F8 (2040)
- dáta čo by mali padnúť na blok číslo 728 (1832) sú presmerované do rezervného bloku 7F7 (2039)
Pošli teda fotku logu okna softu proman aby sme vedeli, aké čísla vadných blokov vypísal.
Cílem tohoto bastlení je opravit daný main board a zároveň ověřit jestli sw, který teď jsem sehnal pro PROMAN programátor (v061) si poradí s K9GAG08 a jestli nee tak to prodám a budu hledat jiný, cenově mi dostupný.
Pravděpodobně jsi misnul přiložený soubor txt ve kterém je výpis programátoru o identifikovaných vadných blocích, přikládám tedy print-screen obrazovky.
Rozdíl je v množství zaznamenaných BB v paměti NAND a množstvím detekovaným PROMANem. Mezi hodnotami BB v NAND D5 01 FB 07 D6 01 FA 07 63 03 F9 07 FD 05 F8 07 28 07 F7 07 chybí 5Fe, kterou zobrazuje log sw programátoru, viz. níže.
BBLK: block469[0x1d500000-0x1d5fffff], with spare area[0x1edf6200-0x1ef03bff]
BBLK: block470[0x1d600000-0x1d6fffff], with spare area[0x1ef03c00-0x1f0115ff]
BBLK: block867[0x36300000-0x363fffff], with spare area[0x39124e00-0x392327ff]
BBLK: block1533[0x5fd00000-0x5fdfffff], with spare area[0x64e97200-0x64fa4bff]
BBLK: block1534[0x5fe00000-0x5fefffff], with spare area[0x64fa4c00-0x650b25ff]
BBLK: block1832[0x72800000-0x728fffff], with spare area[0x78981000-0x78a8e9ff]
BBLK: block2016[0x7e000000-0x7e0fffff], with spare area[0x84b4c000-0x84c599ff]
BBLK: block2073[0x81900000-0x819fffff], with spare area[0x88754a00-0x888623ff][/b]
Po smazání NAND paměti v PROMANU ukazuje log už jen 7 chybných bloků. (To by měly být vadné bloky označené z výroby)
BBLK: block469[0x1d500000-0x1d5fffff], with spare area[0x1edf6200-0x1ef03bff]
BBLK: block470[0x1d600000-0x1d6fffff], with spare area[0x1ef03c00-0x1f0115ff]
BBLK: block867[0x36300000-0x363fffff], with spare area[0x39124e00-0x392327ff]
BBLK: block1533[0x5fd00000-0x5fdfffff], with spare area[0x64e97200-0x64fa4bff]
BBLK: block1832[0x72800000-0x728fffff], with spare area[0x78981000-0x78a8e9ff]
BBLK: block2016[0x7e000000-0x7e0fffff], with spare area[0x84b4c000-0x84c599ff]
BBLK: block2073[0x81900000-0x819fffff], with spare area[0x88754a00-0x888623ff]
Jak tedy postupovat při úpravě funkčního dumpu dále?
Ten 5FE (1534) blok môže byť v druhej BBT.
Skús sa pokúsiť nájsť v dumpe pamäte či neobsahuje ešte jednu BBT, resp. pošli mi link na stiahnutie celého vadného dumpu, ktorý si zo starej nand stiahol. Overím prípadnú existenciu druhej BBT a či obsahuje aj tento blok.
Pre ostatných:
Blok 7E0 (2016) tiež označený promaanom ako vadný patrí do rezervných blokov, takže pokiaľ BBT nemá také množstvo presmerovaní aby sa týkal aj bloku 7E0, netreba to vôbec riešiť.
Potom môžeme ísť dalej.
Ohladne toho čo potom s tým ďalej, tak asi si si všimol, že v logu promana je spare area bloku 1D5 (469) oznaená ako od 1EDF6200 do 1EF03BFF čo je nezmysel.
Je to chyba v softe promanu akým spôsobom vypisuje log o vadných blokoch.
Výpočet počiatčnej a koncovej adresy bloku:
- hexa programátorskou kalkulačkou vo windows sa počíta adresa na základe toho, čo som písal predtým (veľkosť jedného bloku je hexa 100000 (0-FFFFF) + spare 00DA00 hexa (0-D9FF) teda veľkosť jedného bloku je spolu 10DA00 hexa (0-10D9FF)).
Na základe výpočtu v skutočnosti blok číslo 1D5 (469) záčína v dumpe od adresy: 1D5x10DA00=1EDF6200 čo je adresa začiatku celého bloku číslo 1D5 (469) +10D9FF (veľkosť spare každého bloku) = 1EF03BFF čo je koncová adresa celého bloku číslo 1D5 (469) aj s jeho spare oblasťou.
To znamená, že výpis okna promanu
BBLK: block469[0x1d500000-0x1d5fffff], with spare area[0x1edf6200-0x1ef03bff] má chybu.
Blok 469 desiatkovo alebo 1D5 hexa v zamýšlanom dumpe nezačína adresou 1D500000 a nekončí adresou 1D5FFFFF ale platí to, čo je napísané ďalej v logu, že začína v dumpe od 1EDF6200 a končí adresou 1EF03BFF vrátane jeho spare oblasti ako som overil kalkulačkou.
Takže chybu vo výpise logu promana pozor!!!
Nás zaujíma raw (surová veľkosť a dresy blokov a to sú tie čísla na konci každého riadku logu.
To isté samozrejme platí aj o výpise ďaľších vadných blokov v proman logu.
Prečo to píšem?
Na presun dát blokov si musíš správne vypočítať správnu počiatočnú a koncovú adresu bloku na presun.
Pretože ak chceš vytvoriť správny a funkčný dump pre pamäť z ktorej máš BBT, musíš najprv analyzovať BBT funkčného dumpu, ktorý slúži ako darca:
- Pozret či darcovský dump obsahuje BBT a ak áno, potom najprv dáta z rezervných blokov označených v BBT dárcovského dumpu musíš presunúť (prehodiť medzi sebou) na adresy pôvodne vadných blokov.
Tým vytvoríš darcovský dump bez vadných blokov na ďaľšie spracovanie.
Tento dump si samozrejme ulož do súboru ako dárcovský na ďaľšie spracovanie.
Síce takto ako je, by nebol funkčný v TV, lebo BBT čo je v nom by musela spolu s jej ECC byť nahradená BBT a ECC z dumpu bez vadných blokov, ktorý asi nemáš.
Ale ani to nie je potrebné, keďže asi ani nemáš nand pamäť bez vadných blokov.
Ale ako základ dárcovskho dumpu to stačí.
- Ďalej popresúvať (prehodiť medzi sebou) obsahy blokov na dárcovskom dumpe podľa BBT pamäte, pre ktorú chceš dump pripraviť, tak ako sa píše v BBT z tejto pamäte.
A nakoniec skopírovať preplácnuť BBT a jej ECC z pôvodnej pamäte do takto
prichystaného dumpu a tým pôvodnú BBT dárcovského dumpu nahradíš touto, keďže dump chystáš pre túto pamäť.
A až potom máš funkčný dump ušitý pre túto konkrétnu pamäť.
Takže výpočet adries blokov je nutný aby si vedel čo máš a kam presúvať pomocou nejakého hex editoru.
Nemůžete odesílat nové téma do tohoto fóra. Nemůžete odpovídat na témata v tomto fóru. Nemůžete upravovat své příspěvky v tomto fóru. Nemůžete mazat své příspěvky v tomto fóru. Nemůžete hlasovat v tomto fóru. Nemůžete připojovat soubory k příspěvkům Můžete stahovat a prohlížet přiložené soubory
Informace na portálu Elektro bastlírny jsou prezentovány za účelem vzdělání čtenářů a rozšíření zájmu o elektroniku. Autoři článků na serveru neberou žádnou zodpovědnost za škody vzniklé těmito zapojeními. Rovněž neberou žádnou odpovědnost za případnou újmu na zdraví vzniklou úrazem elektrickým proudem. Autoři a správci těchto stránek nepřejímají záruku za správnost zveřejněných materiálů. Předkládané informace a zapojení jsou zveřejněny bez ohledu na případné patenty třetích osob. Nároky na odškodnění na základě změn, chyb nebo vynechání jsou zásadně vyloučeny. Všechny registrované nebo jiné obchodní známky zde použité jsou majetkem jejich vlastníků. Uvedením nejsou zpochybněna z toho vyplývající vlastnická práva. Použití konstrukcí v rozporu se zákonem je přísně zakázáno. Vzhledem k tomu, že původ předkládaných materiálů nelze žádným způsobem dohledat, nelze je použít pro komerční účely! Tento nekomerční server nemá z uvedených zapojení či konstrukcí žádný zisk. Nezodpovídáme za pravost předkládaných materiálů třetími osobami a jejich původ. V případě, že zjistíte porušení autorského práva či jiné nesrovnalosti, kontaktujte administrátory na diskuzním fóru EB.
FAQ
Hledat
Uživatelské skupiny
Profil
Soukromé zprávy
Přihlášení
